- Naming Conversions and Style
- Coding Practices
- Error Handling
- Data Access
- Naming Conversions and Style
- Use Pascal casing for type and method and constants Ex: public class SomeClass
- Use camel casing for local variable names and method arguments Ex:
- 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;
} - Name methods using verb-object pair, such as ShowDialog ().
- Method with return values should have a name describing the value returned, such as GetObjectState ().
- Use descriptive variable names
- Always use C# predefined types rather than the aliases in the System Namespace. For Example:
- Use meaningful namespace such as the product name or the company name.
- Avoid fully qualified type names. Use the using statement instead.
- Avoid putting a using statement inside a namespace.
- Group all framework namespaces together and put custom or third-party namespaces underneath. Example: using System;
- 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.
- Indent comment at the same level of indentation as the code you are documenting.
- All comments should pass spell checking. Misspelled comments indicate sloppy development.
- All member variables should be declared at the top, with one line separating them from the properties or methods. public class MyClass
- Declare a local variable as close as possible to its first use.
- A file name should reflect the class it contains.
- Always place an open curly ({) in a new line.
- Coding Practices:
- 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 method with more than 25 lines.
- Avoid methods with more than 5 arguments. Use structures for passing multiple arguments.
- Do not manually edit any machine generated code.
- If modifying machine generated code, modify the format and style to match this coding standard.
- 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 variables and method names should not require comments.
- Document only operational assumptions, algorithms insights and so on.
- Avoid method level documentation.
- With the exception of zero or 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.
- Every line of code should be walked through in a “white Box” testing manner.
- Catch only exceptions for which you have explicit handling.
- Avoid error code as method return values.
- Avoid defining custom exception classes.
- Avoid multiple Main () methods in a single assembly.
- Make only the most necessary types public. Mark other as internal.
- Avoid friend assemblies. As they increases inter assembly coupling.
- Avoid code that relies on an assembly that running form a particular location.
- Minimize code in application assemblies (EXE client assemblies). Use class libraries instead to contain business logic.
- Always use a curly brace scope in an if statement, even if it contains a single statement.
- Always use zero based arrays.
- Do not provide public or protected member variables. Use properties instead.
- Avoid using “new” inheritance qualifier. Use “override” instead.
- Never use unsafe code. Except using interop.
- Always check a delegate for null before invoking it.
- Classes and Interfaces should have at least 2:1 ratio of methods to properties.
- 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.
- Prefer using explicit interface implementation.
- Never hardcode strings that might change based on deployment such as connection strings.
- When building a long string use “StringBuilder”, not “String”.
- Don’t use late binding invocation when early-binding is possible.
- Use application logging and tracing.
- Never use “go to” unless in a switch statement fall-through.
- Don’t use the “this” reference unless invoking another constructor from within a constructor.
- Avoid casting to and from “System.Object” in code that uses generics. Use constraints or the “as” operator instead.
- 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.
- Error Handling:
- Error handler should be present whenever you anticipate possibility of error.
- Do not use Try-catch for flow- control.
- Never declare an empty catch block.
- Error Message should be user friendly, simple and understandable.
- Errors should be raised in the routines present in the components and captured in the application’s GUI.
- Use Try-Catch statements in each and every function you write. Adhere to it strictly with out fail.
- Use dispose on types holding scarce resources, i.e., files, database connections.
- Data Access:
- ANSI SQL 92 standards have to be followed for writing queries.
- Do not put order by clause in the query unless required.
- Do not encapsulate readonly database operations in transactions.
- Use a stored procedure with output parameters instead of single record SELECT statements when retrieving one row of data.
- 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.
- After each data modification statement inside a transaction, check for an error by testing the global variable @@ERROR
- Verify the row count when performing DELETE operation
- Use RETURN statement in stored procedures to help the calling program know whether the procedure worked properly.
- Key words should be capital. For example; SELECT, UPDATE, DELETE, INSERT, FROM, AND WHERE, etc.
- 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.
- 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 (‘).
- Where multiple columns are selected, there should be a single space after every ‘,’ between two columns.
- All the major keywords should come on the new lines
- 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.
- For any new line separator, the separator should come after a single space after the last word of the line.
- Place a tab after each key word on a new line.
{
const int DefaultSize= 100;
public SomeMethod ()
{ }
}
int number;
void MyMethod (int someNumber)
{ }
object NOT Object
string NOT String
int NOT Int32.
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;
{
int m_Number;
string m_Name;
public void SomeMethod1()
{ }
public void SomeMethod2()
{ }
}
.jpg)
