Los Techies : Blogs about software and anything tech!
Jimmy Bogard » Why we need named parameters

Why we need named parameters


C# 4.0 brings the idea of named parameters to C#.  While optional/default arguments are of questionable value (this is from my VB.NET days), named parameters can really clear up the meaning of a method call.  We’re already faking named parameters, as seen here in the ASP.NET MVC codebase:

return GenerateUrl(
    null /* routeName */, 
    actionName, 
    null /* controllerName */, 
    new RouteValueDictionary(valuesDictionary));

Obviously the above example isn’t compile-time safe and comments lie to you, so it will be nice to be able to provide named parameters, especially when the number of arguments grows in a method call.  Something to look forward to.

Kick It on DotNetKicks.com
Posted Dec 18 2008, 09:10 AM by bogardj
Filed under:

Comments

derick.bailey wrote re: Why we need named parameters
on 12-18-2008 9:29 AM

"especially when the number of arguments grows in a method call"

isn't that usually a design smell to say that you may need to consolidate parameters into DTOs, or re-examine your SoC/SRP?

Joe wrote re: Why we need named parameters
on 12-18-2008 1:24 PM

I concur with Mr. Bailey.

Ben Scheirman wrote re: Why we need named parameters
on 12-18-2008 2:55 PM

I agree with Derik, but it would still be nice to have.  We have loads of APIs out there that look like this today.

Attributes have this, why can't methods?

bogardj wrote re: Why we need named parameters
on 12-18-2008 6:30 PM

@derick

You *may* need to.  But since .NET doesn't have first class hashes like Ruby, long parameter lists are often the only way to go....sometimes.  And I don't know your experience with parameter objects, but mine hasn't been that great.

Also, when two parameters are of the same type, it can be tough to remember what should be what.

James Gregory wrote re: Why we need named parameters
on 12-19-2008 3:27 AM

I think I agree with everyone here. Named parameters shouldn't stop our regular refactoring efforts, but they will make existing code a lot nicer to use.

Rob wrote re: Why we need named parameters
on 12-19-2008 7:44 AM

What I'd like to see is less use of primitive types as parameters to both methods and constructors.  A lot of the problems people have with not being able to "remember what should be what" is that method calls like this shouldn't be taking strings for the names.  

Dew Drop - December 19, 2008 | Alvin Ashcraft's Morning Dew wrote Dew Drop - December 19, 2008 | Alvin Ashcraft's Morning Dew
on 12-19-2008 9:40 AM

Pingback from  Dew Drop - December 19, 2008 | Alvin Ashcraft's Morning Dew

bogardj wrote re: Why we need named parameters
on 12-19-2008 9:48 AM

@Rob

So the example I had was Regex.IsMatch - both are strings, and should be, but the order is important.  Named parameters would eliminate bugs and confusion.

But definitely get your drift - strongly-typed reflection goes a long way to eliminating "magic strings".

Ben wrote re: Why we need named parameters
on 12-19-2008 10:19 AM

Named parameters would be nice to have. But isn't this solved by overloads?

bogardj wrote re: Why we need named parameters
on 12-19-2008 10:56 AM

@Ben

No, see my previous comment.  Overloads and fluent builders are sometimes just hacks around doing named parameters.

Jason Olson wrote re: Why we need named parameters
on 12-20-2008 2:44 AM

There's another simple example of why named parameters are nice: boolean parameters. If I have a couple of boolean parameters, what do they mean?

myClass.SomeMethod(true, false, true);

How do I know what that does? Named parameters will help us developers write maintainable code that developers can more easily read after-the-fact without having to rely on Intellisense (after all, I HATE reading code where I _have_ to rely on Intellisense to figure out what the heck is going on)...

Add a Comment

(required)  
(optional)
(required)  
Remember Me?

Enter the numbers above:
Copyright Los Techies 2008, 2009. All rights reserved.
Powered by Community Server (Commercial Edition), by Telligent Systems