Dotnet Coding Standards

We Fallow the Coding Standards to enforce consistent style and formatting in developing the applications. Here I am explaining the following things.

• Naming Conversions and Style
• Coding Practices
• Error Handling
• Data Access

1. Naming Conversions and Style
1. Use Pascal casing for type and method and constants
Ex: public class SomeClass
{
const int DefaultSize= 100;
public SomeMethod ()
{ }
}

2. Use camel casing for local variable names and method arguments
Ex:
int number;
void MyMethod (int someNumber)
{ }

3. Prefix member variables with m_. Use Pascal casing for the rest of a member variable name following the m_.
   Ex:public class SomeClass
   {
   private int m_Number;
   }
   
4. Name methods using verb-object pair, such as ShowDialog ().
5. Method with return values should have a name describing the value returned, such as GetObjectState ().
6. Use descriptive variable names
7. Always use C# predefined types rather than the aliases in the System Namespace.
For Example:
object NOT Object
string NOT String
int NOT Int32.

8. Use meaningful namespace such as the product name or the company name.
9. Avoid fully qualified type names. Use the using statement instead.
10. Avoid putting a using statement inside a namespace.
11. Group all framework namespaces together and put custom or third-party namespaces underneath.
Example: using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using MyCompany;
using MyControl;

12. Maintain strict indentation. Do not use Tabs or non standard indentation. Such as one space. Recommended values are three or four spaces, and the value should be uniformed across.
13. Indent comment at the same level of indentation as the code you are documenting.
14. All comments should pass spell checking. Misspelled comments indicate sloppy development.
15. All member variables should be declared at the top, with one line separating them from the properties or methods.
public class MyClass
{
int m_Number;
string m_Name;
public void SomeMethod1()
{ }
public void SomeMethod2()
{ }
}

16. Declare a local variable as close as possible to its first use.
17. A file name should reflect the class it contains.
18. Always place an open curly ({) in a new line.


2. Coding Practices:
1. Avoid putting multiple classes in a single file.
2. A single file should contribute types to only a single namespace. Avoid having multiple namespaces in the same file.
3. Avoid files with more than 500 lines (Excluding machine-Generated code)
4. Avoid method with more than 25 lines.
5. Avoid methods with more than 5 arguments. Use structures for passing multiple arguments.
6. Do not manually edit any machine generated code.
7. If modifying machine generated code, modify the format and style to match this coding standard.
8. Use partial classes whenever possible to factor out the maintained portions.
9. Avoid comments that explain the obvious. Code should be self-explanatory. Good code with readable variables and method names should not require comments.
10. Document only operational assumptions, algorithms insights and so on.
11. Avoid method level documentation.
12. With the exception of zero or one, never hard-code a numeric value; always declare a constant instead.
13. Use the const directive only on natural constants such as the number of days of the week.
14. Avoid using const on read-only variables. For that, use the readonly directive.
15. Every line of code should be walked through in a “white Box” testing manner.
16. Catch only exceptions for which you have explicit handling.
17. Avoid error code as method return values.
18. Avoid defining custom exception classes.
19. Avoid multiple Main () methods in a single assembly.
20. Make only the most necessary types public. Mark other as internal.
21. Avoid friend assemblies. As they increases inter assembly coupling.
22. Avoid code that relies on an assembly that running form a particular location.
23. Minimize code in application assemblies (EXE client assemblies). Use class libraries instead to contain business logic.
24. Always use a curly brace scope in an if statement, even if it contains a single statement.
25. Always use zero based arrays.
26. Do not provide public or protected member variables. Use properties instead.
27. Avoid using “new” inheritance qualifier. Use “override” instead.
28. Never use unsafe code. Except using interop.
29. Always check a delegate for null before invoking it.
30. Classes and Interfaces should have at least 2:1 ratio of methods to properties.
31. Avoid Interfaces with one member. Strive to have three to five members per interface. Don’t have more than 20 members per interface.12 is probably principle limit.
32. Prefer using explicit interface implementation.
33. Never hardcode strings that might change based on deployment such as connection strings.
34. When building a long string use “StringBuilder”, not “String”.
35. Don’t use late binding invocation when early-binding is possible.
36. Use application logging and tracing.
37. Never use “go to” unless in a switch statement fall-through.
38. Don’t use the “this” reference unless invoking another constructor from within a constructor.
39. Avoid casting to and from “System.Object” in code that uses generics. Use constraints or the “as” operator instead.
40. Do not use the base word to access base class members unless you wish to resolve a conflict with a subclasses member of the same name or when invoking a base class constructor.


3. Error Handling:
1. Error handler should be present whenever you anticipate possibility of error.
2. Do not use Try-catch for flow- control.
3. Never declare an empty catch block.
4. Error Message should be user friendly, simple and understandable.
5. Errors should be raised in the routines present in the components and captured in the application’s GUI.
6. Use Try-Catch statements in each and every function you write. Adhere to it strictly with out fail.
7. Use dispose on types holding scarce resources, i.e., files, database connections.


4. Data Access:
1. ANSI SQL 92 standards have to be followed for writing queries.
2. Do not put order by clause in the query unless required.
3. Do not encapsulate readonly database operations in transactions.
4. Use a stored procedure with output parameters instead of single record SELECT statements when retrieving one row of data.
5. Stored procedure execution is fast when we pass parameters by position (the order in which the parameters are declared in the stored procedure) rather then by name.
6. After each data modification statement inside a transaction, check for an error by testing the global variable @@ERROR
7. Verify the row count when performing DELETE operation
8. Use RETURN statement in stored procedures to help the calling program know whether the procedure worked properly.
9. Key words should be capital. For example; SELECT, UPDATE, DELETE, INSERT, FROM, AND WHERE, etc.
10. Do not use “SELECT * FROM” type of query. If all the columns of the table are to be selected, list all columns in the SELECT in same order as they appear in the table definition.
11. While writing a query as a string, do not put any space after single quote (‘). There should be a single space between every two words. There should not be a space between the last word and the concluding single quote (‘).
12. Where multiple columns are selected, there should be a single space after every ‘,’ between two columns.
13. All the major keywords should come on the new lines
14. The number of columns in a SELECT statement should not be more than 6. The line separator should be placed in this case after the (,) of the last column of this line and a single space.
15. For any new line separator, the separator should come after a single space after the last word of the line.
16. Place a tab after each key word on a new line.