Standard Coding Practices in .NET
February 2, 2010 by: Sanket|
A comprehensive coding standard is essential for a successful product delivery. The standard helps in enforcing best practices and avoiding pitfalls, and makes knowledge dissemination across the team easier. The C# coding standard presented here is very thin on the “why” and very detailed on the “what” and the “how.” The coding standard presented next captures best practices, dos and don’ts, pitfalls, guidelines, and recommendations, as well as naming conventions and styles, project settings and structure, and framework specific guidelines. |
Standard Coding Practices in .NET
· Avoid putting multiple classes in a single file.
· A single file should contribute types to only a single namespace. Avoid having multiple namespaces in the same file.
· Avoid files with more than 500 lines (excluding machine-generated code).
· Avoid methods with more than 200 lines.
· Avoid methods with more than 5 arguments. Use structures for passing multiple arguments.
· Lines should not exceed 120 characters.
· Do not manually edit any machine-generated code.
o If modifying machine generated code, modify the format and style to match this coding standard.
o Use partial classes whenever possible to factor out the maintained portions.
· Avoid comments that explain the obvious. Code should be self-explanatory. Good code with readable variable and method names should not require comments.
· Document only operational assumptions, algorithm insights and so on.
· Avoid method-level documentation.
o Use extensive external documentation for API documentation.
o Use method-level comments only as tool tips for other developers.
· With the exception of zero and one, never hard-code a numeric value; always declare a constant instead.
· Use the const directive only on natural constants such as the number of days of the week.
· Avoid using const on read-only variables. For that, use the readonly directive.
· Assert every assumption. On average, every fifth line is an assertion.
· Every line of code should be walked through in a “white box” testing manner.
· Catch only exceptions for which you have explicit handling.
· In a catch statement that throws an exception, always throw the original exception (or another exception constructed from the original exception) to maintain the stack location of the original error:
Catch (Exception exception)
{
MessageBox.Show(exception.Message);
throw;
}
· Avoid error codes as method return values.
· Avoid defining custom exception classes.
· When defining custom exceptions:
o Derive the custom exception from Exception.
o Provide custom serialization.
· Avoid multiple Main () methods in a single assembly.
· Make only the most necessary types public, mark others as internal.
· Avoid friend assemblies, as they increase inter-assembly coupling.
· Avoid code that relies on an assembly running from a particular location.
· Minimize code in application assemblies (EXE client assemblies). Use class libraries instead to contain business logic.
