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 */, 
    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.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in C#. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • “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

    I concur with Mr. Bailey.

  • 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?

  • @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.

  • 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

    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.

  • @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

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

  • @Ben

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

  • 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)…