Friday, October 10, 2008 10:07 AM mohanbrij

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.

     

     

    Filed under: , ,

    Comments

    # re: C# Coding Standards by Lance's

    Friday, October 10, 2008 7:43 AM by JV

    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.

    # re: C# Coding Standards by Lance's

    Friday, October 10, 2008 8:16 AM by mohanbrij

    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.

    # re: C# Coding Standards by Lance's

    Friday, October 10, 2008 9:02 AM by AndrewSeven

    That seems to have improved since that last time I looked at it, but all the same, I would suggest using the "Framework Design Guidelines" as the starting point for  any coding guideline.

    If you want to be strict, you can use Style Cop, but it has several rules like spaces vs. tabs that some of us don't like.

    From the Framework Design Guidelines:

    "DO name Generic parameters with descriptive names, unless a single-letter name is completely self-explanatory and a descriptive name would not add value"

    "Consider using T as the type parameter name for types with ONE single-letter type parameter"

    "Do prefix type parameter names with T"

    "Consider indicating constraints placed on a type parameter in the name of the parameter"

    # re: C# Coding Standards by Lance's

    Friday, October 10, 2008 11:29 AM by JV

    @mohanbrij: I understand the reasoning why to use prefixes, but my most important argument is that you can also easily see that something is a private variable without the underscore (Even without using intellisense and syntax highlighting). The same arguments for enums,classes etc fit for those private variables. Even in notepad it's easily distinquisable when you use the approriate casing (Which is also defined in the document).

    But I do think it's a minor thing (I don't even wanna call it an issue/problem). It's a good document :). It's just something I see in lots of guidelines, but whenever I confront the author with it, it always ends up in: "I prefer/like to do this this way" (Nothing wrong with that) or legacy reasons. So I'm always intrested in the thoughts behind it :)

    # Interesting Finds: 2008.10.12

    Saturday, October 11, 2008 10:24 PM by gOODiDEA

    .NET ASP.NETMVCandthenewIIS7RewriteModule

    My10commonmistakesinASP.NET

    C#CodingS...

    # re: C# Coding Standards by Lance's

    Tuesday, December 16, 2008 9:21 AM by Robert

    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

    Leave a Comment

    (required) 
    (required) 
    (optional)
    (required)