C# Coding Guidelines for better programming

C# Coding Guidelines for Better Programming

Have you come across deja vu situation where you have worked on multiple projects and most of them face the same situation where you find that the code consistency is affected by the lack of standards/guidelines?

The organization does not have specific or concrete coding guidelines and checklists pertaining to your project and this results in the same mistakes being done over and over again by the teams on various projects.

Lack of checklist also enables in unnecessary code review flare offs where team members do not accept the code review comments as they do not adhere to consistent guidelines.

The better way to approach this would be to have various coding standards checklists where it is marked which guidelines are mandatory and which are nice to have and the better way is to have such guidelines set as rules in your static code analysis tool/s so that the code reviewer can shift focus to reviewing code for better programming practices than to trivial misses which if not adhered to will soon turn into technical debts.

In case you have been asked to consider the best practices, I will defer to say that these practices can be better practices based on the context and usage and will help your code to get better or cleaner.

I am listing below some better coding guidelines for C# — these are definitely not exhaustive, but they give a glimpse into this ocean of infinity.

1. Class Names
   * Noun phrases
2. Method names
   * Verb phrases
3. Functions (methods)
   * Small and do only one thing
4. Comments
   * Informative focussing on intent
   * Place the comment on a separate line, not at the end of a line of code
   * Begin comment text with an uppercase letter
   * End comment text with a period
   * Insert one space between the comment delimiter (//) and the comment text
5. Formatting
   * Indent properly and line-break even short constructs
   * Write only one statement per line
   * Write only one declaration per line
   * If continuation lines are not indented automatically, indent them one tab stop (four spaces)
   * Add at least one blank line between method definitions and property definitions
   * Use parentheses to make clauses in an expression apparent
6. Exceptions
   Provide intent, context and error type detail
7. Declarations
   Declare constants before variables before methods
8. Classes
   Small having only one responsibility.
9. Naming
   * Use pascal casing (“PascalCasing”) when naming a class, record, or struct
   * Use camel casing (“camelCasing”) when naming private or internal fields, and prefix them with _
10. String Manipulation
    * Use string interpolation to concatenate short strings
    * To append strings in loops, especially when you’re working with large amounts of text, use a StringBuilder object
11. Variables
    * Use implicit typing(var) for local variables when the type of the variable is obvious from the right side of the assignment, or when the precise type is not important
    * Don’t use var when the type is not apparent from the right side of the assignment. Don’t assume the type is clear from a method name. A variable type is considered clear if it’s a new operator or an explicit cast.
    * Don’t rely on the variable name to specify the type of the variable. It might not be correct.
    * Avoid the use of var in place of dynamic. Use dynamic when you want run-time type inference.
    * Use implicit typing to determine the type of the loop variable in for loops.
    * Don’t use implicit typing to determine the type of the loop variable in foreach loops.

I wish to continue with these guidelines in further articles so that we can cover more.

References:

C# Coding Conventions