Why should you attack incorrect parameter name casing now?

Who cares if your C# method parameters are called “int customerId”, “int CustomerID” or whatever? Well, soon you will!

For the short history of C#, method parameter names have been like private variables to C# developers: Their names don’t make a difference and can be changed at any time.

Yet technically, changing method argument names is an API breaking change. C# developers haven’t cared much, since the language has only supported positional arguments – with “GetCustomer(int id)”, the first argument gets mapped to id no matter what its name happens to be.

Now that C# 4.0 will support named parameters at call sites, the naming gets more critical. Once somebody calls GetCustomer(id: 5), any renaming of the parameter is a breaking change – including scenarios where just the case of the parameter changes.

But even more, having the parameter name visible at call site makes the naming more relevant, and non-uniform naming causes irritation. So if you have a nasty habit of mixing IDs, Ids and ids over there, now would be a good idea to change that. You might break some VB.NET or reflection code already, but if you have such callers, you probably cared about parameter names already.

What if you don’t have parameter naming conventions?

Try these:

Start with MSDN’s Parameter Naming Guidelines
Only two-letter acronyms (UI, IO etc.) should be uppercase; longer ones are considered words (ftpClient, targetUri). See the special guidelines on abbreviations.
Id is written with a lowercase d (it is not an acronym)

But really, any convention will do. It’s more about creating consistency within your organization, although following the Microsoft’s guidelines does give you the additional benefit of your code mixing better with the code coming in from the rest of the world.

September 7, 2009 · Jouni Heikniemi · No Comments
Tags: C#, coding conventions · Posted in: .NET