Note
This content is reprinted by permission of Pearson Education, Inc. from Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. That edition was published in 2008, and the book has since been fully revised in the third edition. Some of the information on this page may be out-of-date.
Beyond the obvious reason of readability, it is important to follow the guidelines for parameter names because parameters are displayed in documentation and in the designer when visual design tools provide Intellisense and class browsing functionality.
âï¸ DO use camelCasing in parameter names.
âï¸ DO use descriptive parameter names.
âï¸ CONSIDER using names based on a parameterâs meaning rather than the parameterâs type.
Naming Operator Overload Parametersâï¸ DO use left and right for binary operator overload parameter names if there is no meaning to the parameters.
âï¸ DO use value for unary operator overload parameter names if there is no meaning to the parameters.
âï¸ CONSIDER meaningful names for operator overload parameters if doing so adds significant value.
â DO NOT use abbreviations or numeric indices for operator overload parameter names.
Portions © 2005, 2009 Microsoft Corporation. All rights reserved.
Reprinted by permission of Pearson Education, Inc. from Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition by Krzysztof Cwalina and Brad Abrams, published Oct 22, 2008 by Addison-Wesley Professional as part of the Microsoft Windows Development Series.
See alsoRetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4