Even Microsoft Does It

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.