MS.NET Specially C# Coding Standards

Naming convention's to be followed while programming in Visual Studio.NET

Declaration	Casing To be Used		Preferences
Namespace	Pascal Casing
Class	Pascal Casing
Enumerator Types	Pascal Casing
Enumerator Values	Pascal Casing
Interface	Pascal Casing		Always start with “I”
Exception Classes	Pascal Casing		Always end with “Exception”
Public Fields	Pascal Casing
Protected Fields	camel Casing
Private Fields	camel Casing		Start with _(Underscore)
Methods	Pascal Casing
Property	Pascal Casing
Parameter of Method	camel Casing
Static Member	Pascal Casing
Event	Pascal Casing
Delegate	Pascal Casing
Constant Variable	Upper Casing

Note:
In Pascal Casing – First character of the identifier will be in upper case and in the same identifier a new word should again begin with uppercase.
Eg: HelloApp, NameOfVariable

In camel Casing – First character is always lowercase and rest is same as Pascal casing.

Commenting Style

Every user defined classes, interfaces, enumerators and Methods should have following comments above them.

Purpose:
Created on:
Created by:
Modified on:
Modified by:
Status: Completed (InCompleted \Completed \Tested \Used)
public void Foo()
{ . . . }

INDENTATION and SPACES

Wrapping Lines
When an expression will not fit on a single line, break it up according to these general principles:
·         Break after a comma.
·         Break after an operator.
·         Prefer higher-level breaks to lower-level breaks.
·         Align the new line with the beginning of the expression at the same level on the previous line

White Spaces
Don't use spaces for indentation - use tabs!

Class and Interface Declaration

·         When coding C# classes and interfaces, the following formatting rules should be followed:
·         No space between a method name and the parenthesis "(" starting its parameter list.
·         The opening brace "{" appears in the next line after the declaration statement.
·         The closing brace " }" starts a line by itself indented to match its corresponding opening braces

Blank Lines

Blank lines improve readability. They set off blocks of code which are in themselves logically related.

Two blank lines should always be used between:
·         Logical sections of a source file
·         Class and interface definitions (try one class/interface per file to prevent this case)

One blank line should always be used between:
·         Methods
·         Properties
·         Local variables in a method and its first statement
·         Logical sections inside a method to improve readability

Note that blank lines must be indented as they would contain a statement this makes insertion in these lines much easier

Single spaces surround operators (except unary operators like increment or logical not),
Example: a = b; // don't use a=b;


Thankyou and Wishing You MOST and MORE successful career ahead.