Sign In

Navigation

On This Page

Archive

<October 2009>
SunMonTueWedThuFriSat
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567

Categories

Blogroll

Contact

Send mail to the author(s) Email Me
MCPD
MCTS

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way


Copyright ©  2010
 Creative Commons License
This work by Jeff Klawiter is, unless explicitly stated in the article,  available under the Creative Commons Attribution 3.0 United States License.

Pick a theme:
# Tuesday, October 27, 2009
by Jeff Klawiter - Tuesday, October 27, 2009 10:04:59 AM (Central Standard Time, UTC-06:00)

C# 4.0 introduces many new languages features, one of them being named parameters. Instead of passing parameters to a method or constructor in the sequence they are declared you can pass them in as a name/value pair.

//method signature
public SearchData(string searchText, SearchOptions SearchOption, int limit, int skip)

//Calling it the normal way
obj.SearchData("foo",mySearchOptions,10,20);

//Calling it with Named Parameters
obj.SearchData(limit: 10, skip: 20, searchText: "foo", SearchOption: mySearchOptions);

As you can see it is nice that now when passing parameters your code becomes more self documenting. You know what parameter is being assigned to what. Combine this with default/optional parameters it can make your code more clear and concise.

The problem comes when refactoring code. I hope you noticed something wrong about the second parameter in the method signature. While technically sound it fails naming guidelines. Say this was a third party library you were using and they discovered this and fixed it in the next revision. When you update to the new library you will get a compiler error. This is because the named parameters are Case Sensitive. Below is an example of just this

//New method signature
public SearchData(string searchText, SearchOptions searchOption, int limit, int skip)

//This will remain working
obj.SearchData("foo",mySearchOptions,10,20);

//This will now result in a compiler error
obj.SearchData(limit: 10, skip: 20, searchText: "foo", SearchOption: mySearchOptions);

Now I’m not saying you should never use Named Parameters. You should keep in mind if you are using code that is not your own you may be increasing your development debt. Also take into account where the code comes from. If you are doing Office development, I say go for it. Microsoft is very aware of implications of this and will no doubt do their due diligence when updating the Primary Interop Assemblies.

I also am hoping that Visual Studio 2010 will have refactoring support when renaming a parameter like that. I just tried in Beta 2 and did not get any such support. Maybe Resharper will catch it.

Comments [0] #       |  kick it on DotNetKicks.com Shout it
All comments require the approval of the site owner before being displayed.
Name
E-mail
(will show your gravatar icon)
Home page

Comment (Some html is allowed: a@href@title, b, blockquote@cite, em, i, strike, strong, sub, sup, u) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

Enter the code shown (prevents robots):

Live Comment Preview