C# Coding Standards by Lance's

Following the right Coding standars comes with Practice and proper Guidance if you are a starter, and also lots of companies define or customize their own coding standards.

When I came across this challange to define the coding standard for my team, I thought instead of reinventing the wheel and recollecting everything from my experience, better if I get something which is already defined and documented. So I started googling and came across a very good document which covers almost all the aspects of C# Coding standards which I was looking for. This Document covers the following topics*

  • Cover all major C# Language features.
  • Provide guidelines on coding style & language usage (but not syntax)
  • Demonstrate all rules in code where applicable.
  • Describe rules in structure that is easy to read & use.
  • Define clear & concise rules.
  • Use consistent terminology & rule patterns.
  • Only provide rules where there is a clear cut best practice.
  • Lead developers to a "pit of success" and avoid common "pits of failure"

    • You can download the PDF from here http://weblogs.asp.net/lhunt/attachment/591275.ashx

    Original Post you can find here : http://weblogs.asp.net/lhunt/pages/CSharp-Coding-Standards-document.aspx

     Thanks

    ~Brij

    * All the Copyrights in this Post are the property of the Respective Owner.

     

     

    3 Comments

    • Nice guidelines indeed, however it does contain some contradictions. Eg 2.1.16 says "Do not use public enum ColorEnum" (avoid redundant or meaningless prefixes and suffixes), but in 1.4.1 and 2.2 he does use redundant/meaningless prefixes (the "_") several times. Those are not necesary at all in C# and the goal when you use them is the same as using suffixes for ColorEnum.

    • Hi JV,
      In Line 2.1.16, When he said avoid adding redundant or meaningless prefixes or suffixes, it means when we are defining enums, we already know this is enum, so it looks redundant when we name something like ColorEnum, similarly for Struct, Class, etc.

      Also in Section 1.4.1 and 2.2, accordint to microsoft coding standards its good practice to prefix the private variable (field, constant, static fields) with _underscores, similarly in section 2.2 please see he is using only the private variables with _usderscores.

      What I found good in this document is it covers almost everything, section 5 also explains the important Object Model and Design API in very few words. Which is all we need very often.

    • In our coding experience, we found it incredibly useful and important to be able to instantly distinguish between a class level field and a local function level variable. using the same naming guidelines for both (ie, camel casing) can be confusing. Prepending the _ onto the field level variable instantly identifies it as a such.

      Rob

    Comments have been disabled for this content.