If you create a new MVC 3 application in Visual Studio 2010, and look in the account controller, you’ll see the following line:
FormsAuthentication.SetAuthCookie( model.UserName, false /* createPersistentCookie */);
Hasn’t anybody noticed C# 4.0 introduced named parameters? This was an incredibly welcome language addition to me. Here’s how I would have written the above, along with some good and bad examples demonstrating why named parameters are a good thing for readability and maintainability:
FormsAuthentication.SetAuthCookie( model.UserName, createPersistentCookie:false ); // bad: something.DoIt( true, false, true, 60 ); // good: something.DoIt( updateDatabase:true, sendNotificationEmails:false, backupFirst:true, timeoutSeconds: 60 ); // and a lot less clunky (and verbose) than this: var updateDatabase = true; var sendNotifcationEmails = false; var backupFirst = true; var timeoutSeconds = 60; something.DoIt( updateDatabase, sendNotificationEmails, backupFirst, timeoutSeconds ); );
Okay, so “something” is a terrible name for a variable, and “DoIt” is a terrible name for a method, but at least we have some hints as to what those mysterious parameters are for!
This language feature essentially boils down to is documentation. For some parameters, like well-named object instances, or self-explanatory strings, it’s not necessary. But for context-less data types like booleans and integers, it makes a lot of sense.