Question

I really this is a hugely subjective topic but here is my current take:

When calling methods which do not form part of the .NET BCL named parameters should always be used as the method signatures may well change, especially during the development cycle of my own applications.

Although they might appear more verbose they are also far clearer.

Is the above a reasonable approach to calling methods or have I overlooked something fundamental?

Answer 1

I think it’s over the top, personally. (I also believe it’s more correct and clearer to call them named arguments – the parameters always have names, as that’s part of the declaration.)

In many cases the meaning is crystal clear from the method name – particularly if there are only a couple of arguments. Why bother to add the name? Why does the fact that the name may change affect this?

I would suggest using named arguments:

• When optional parameters are also being used
• When there are multiple parameters of the same type, so they can be confused (e.g. a dialog box’s title and content text)
• When you’re using null for an argument, and it’s not clear what it’s doing

To put it another way, how often did not having named arguments cause you confusion before C# 4? In my case it’s certainly a non-zero number of times – the situations above do happen – but it’s not something that regularly got in my way. Optional parameters make it more reasonable for a method (or particularly a constructor) to have potentially many parameters, and that leads to named arguments being more useful (and indeed necessary if you want to specify “late” optional parameters having skipped earlier ones).