Freigeben über


Coding Standards

Rido has post a kind of poll about the naming of private members. Some comments on using PascalCase, camelCase, _undescore...

IMHO, the point is to have consensus on the development team. That can be a personal -very subjective- preference, with similar arguments in each case -more readable, more meaningful...-.

What I think can be a strong advantage is to have a tool which can control the adherence to the standard. FxCop is one of this tools, but it basically works with the members of an assembly. Hopefully soon we can have another tool, with a similar purpose of FxCop, working with the source code. A starting point could be Code Inspector.

Comments

  • Anonymous
    February 10, 2004

    What's the purpose of the poll? The dotNet class designers guidelines clearly state what is best practice and what is not.

    ms-help://MS.MSDNQTR.2004JAN.1033/cpgenref/html/cpconNETFrameworkDesignGuidelines.htm

    camelCase for private members. Any other way is not the best practice way.
  • Anonymous
    February 10, 2004

    Capitilization Styles
    ms-help://MS.MSDNQTR.2004JAN.1033/cpgenref/html/cpconCapitalizationStyles.htm

    Case Sensitivity
    ms-help://MS.MSDNQTR.2004JAN.1033/cpgenref/html/cpconCaseSensitivity.htm

  • Anonymous
    February 10, 2004
    My understanding is that the Framework Design Guidelines provides guidance on the public and protected members, but not necessarily on the private members, and clearly not on the variables defined on a method.

  • Anonymous
    March 19, 2004
    Jose you are right, the Framework design guidelines only provides guidance on the public and protected members.
    We prefer to use an underscore as a first letter, because the camelCase can have some problems in Visual Basic, if you declare a class property with the same name of the private member.