C# 4.0 Named Parameters - should they always be used when calling non-Framework methods?

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 th开发者_如何转开发e 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?

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).