Coding Conventions in .net

Namespace Naming Guidelines
The general rule for naming namespaces is to use the company name followed by the technology name and optionally the feature and design as follows.
CompanyName.TechnologyName[.Feature][.Design]
For example:
Microsoft.Media
Microsoft.Media.Design
Prefixing namespace names with a company name or other well-established brand avoids the possibility of two published namespaces having the same name. For example, Microsoft.Office is an appropriate prefix for the Office Automation Classes provided by Microsoft.
Use a stable, recognized technology name at the second level of a hierarchical name. Use organizational hierarchies as the basis for namespace hierarchies. Name a namespace that contains types that provide design-time functionality for a base namespace with the .Design suffix. For example, the System.Windows.Forms.Design Namespace contains designers and related classes used to design System.Windows.Forms based applications.
A nested namespace should have a dependency on types in the containing namespace. For example, the classes in the System.Web.UI.Design depend on the classes in System.Web.UI. However, the classes in System.Web.UI do not depend on the classes in System.Web.UI.Design.
You should use Pascal case for namespaces, and separate logical components with periods, as in Microsoft.Office.PowerPoint. If your brand employs nontraditional casing, follow the casing defined by your brand, even if it deviates from the prescribed Pascal case. For example, the namespaces NeXT.WebObjects and ee.cummings illustrate appropriate deviations from the Pascal case rule.
Use plural namespace names if it is semantically appropriate. For example, use System.Collections rather than System.Collection. Exceptions to this rule are brand names and abbreviations. For example, use System.IO rather than System.IOs.
Do not use the same name for a namespace and a class. For example, do not provide both a Debug namespace and a Debug class.
Finally, note that a namespace name does not have to parallel an assembly name. For example, if you name an assembly MyCompany.MyTechnology.dll, it does not have to contain a MyCompany.MyTechnology namespace.

Interface Naming Guidelines
The following rules outline the naming guidelines for interfaces:
• Name interfaces with nouns or noun phrases, or adjectives that describe behavior. For example, the interface name IComponent uses a descriptive noun. The interface name ICustomAttributeProvider uses a noun phrase. The name IPersistable uses an adjective.
• Use Pascal case.
• Use abbreviations sparingly.
• Prefix interface names with the letter I, to indicate that the type is an interface.
• Use similar names when you define a class/interface pair where the class is a standard implementation of the interface. The names should differ only by the letter I prefix on the interface name.
• Do not use the underscore character (_).
The following are examples of correctly named interfaces.
[Visual Basic]
Public Interface IServiceProvider
Public Interface IFormatable
[C#]
public interface IServiceProvider
public interface IFormatable
The following code example illustrates how to define the interface IComponent and its standard implementation, the class Component.
[Visual Basic]
Public Interface IComponent
' Implementation code goes here.
End Interface

Public Class Component
Implements IComponent
' Implementation code goes here.
End Class

[C#]
public interface IComponent
{
// Implementation code goes here.
}
public class Component: IComponent
{
// Implementation code goes here.
}

Attribute Naming Guidelines
You should always add the suffix Attribute to custom attribute classes. The following is an example of a correctly named attribute class.
[Visual Basic]
Public Class ObsoleteAttribute
[C#]
public class ObsoleteAttribute{}

Enumeration Type Naming Guidelines
The enumeration (Enum) value type inherits from the Enum Class. The following rules outline the naming guidelines for enumerations:
• Use Pascal case for Enum types and value names.
• Use abbreviations sparingly.
• Do not use an Enum suffix on Enum type names.
• Use a singular name for most Enum types, but use a plural name for Enum types that are bit fields.
• Always add the FlagsAttribute to a bit field Enum type.
Static Field Naming Guidelines
The following rules outline the naming guidelines for static fields:
• Use nouns, noun phrases, or abbreviations of nouns to name static fields.
• Use Pascal case.
• Do not use a Hungarian notation prefix on static field names.
• It is recommended that you use static properties instead of public static fields whenever possible.
Parameter Naming Guidelines
It is important to carefully follow these parameter naming guidelines because visual design tools that provide context sensitive help and class browsing functionality display method parameter names to users in the designer. The following rules outline the naming guidelines for parameters:
• Use camel case for parameter names.
• Use descriptive parameter names. Parameter names should be descriptive enough that the name of the parameter and its type can be used to determine its meaning in most scenarios. For example, visual design tools that provide context sensitive help display method parameters to the developer as they type. The parameter names should be descriptive enough in this scenario to allow the developer to supply the correct parameters.
• Use names that describe a parameter's meaning rather than names that describe a parameter's type. Development tools should provide meaningful information about a parameter's type. Therefore, a parameter's name can be put to better use by describing meaning. Use type-based parameter names sparingly and only where it is appropriate.
• Do not use reserved parameters. Reserved parameters are private parameters that might be exposed in a future version if they are needed. Instead, if more data is needed in a future version of your class library, add a new overload for a method.
• Do not prefix parameter names with Hungarian type notation.
The following are examples of correctly named parameters.
[Visual Basic]
GetType(typeName As String)As Type
Format(format As String, args() As object)As String
[C#]
Type GetType(string typeName)
string Format(string format, object[] args)

Method Naming Guidelines
The following rules outline the naming guidelines for methods:
• Use verbs or verb phrases to name methods.
• Use Pascal case.
The following are examples of correctly named methods.
RemoveAll()
GetCharArray()
Invoke()
Property Naming Guidelines
The following rules outline the naming guidelines for properties:
• Use a noun or noun phrase to name properties.
• Use Pascal case.
• Do not use Hungarian notation.
• Consider creating a property with the same name as its underlying type. For example, if you declare a property named Color, the type of the property should likewise be Color. See the example later in this topic.
The following code example illustrates correct property naming.
[Visual Basic]
Public Class SampleClass
Public Property BackColor As Color
' Code for Get and Set accessors goes here.
End Property
End Class
[C#]
public class SampleClass
{
public Color BackColor
{
// Code for Get and Set accessors goes here.
}
}
The following code example illustrates providing a property with the same name as a type.
[Visual Basic]
Public Enum Color
' Insert code for Enum here.
End Enum
Public Class Control
Public Property Color As Color
Get
' Insert code here.
End Get
Set
' Insert code here.
End Set
End Property
End Class
[C#]
public enum Color
{
// Insert code for Enum here.
}
public class Control
{
public Color Color
{
get {// Insert code here.}
set {// Insert code here.}
}
}
The following code example is incorrect because the property Color is of type Integer.
[Visual Basic]
Public Enum Color
' Insert code for Enum here.
End Enum
Public Class Control
Public Property Color As Integer
Get
' Insert code here.
End Get
Set
' Insert code here.
End Set
End Property
End Class
[C#]
public enum Color {// Insert code for Enum here.}
public class Control
{
public int Color
{
get {// Insert code here.}
set {// Insert code here.}
}
}
In the incorrect example, it is not possible to refer to the members of the Color enumeration. Color.Xxx will be interpreted as accessing a member that first gets the value of the Color property (type Integer in Visual Basic or type int in C#) and then accesses a member of that value (which would have to be an instance member of System.Int32).
Event Naming Guidelines
The following rules outline the naming guidelines for events:
• Use Pascal case.
• Do not use Hungarian notation.
• Use an EventHandler suffix on event handler names.
• Specify two parameters named sender and e. The sender parameter represents the object that raised the event. The sender parameter is always of type object, even if it is possible to use a more specific type. The state associated with the event is encapsulated in an instance of an event class named e. Use an appropriate and specific event class for the e parameter type.
• Name an event argument class with the EventArgs suffix.
• Consider naming events with a verb. For example, correctly named event names include Clicked, Painting, and DroppedDown.
• Use a gerund (the "ing" form of a verb) to create an event name that expresses the concept of pre-event, and a past-tense verb to represent post-event. For example, a Close event that can be canceled should have a Closing event and a Closed event. Do not use the BeforeXxx/AfterXxx naming pattern.
• Do not use a prefix or suffix on the event declaration on the type. For example, use Close instead of OnClose.
• In general, you should provide a protected method called OnXxx on types with events that can be overridden in a derived class. This method should only have the event parameter e, because the sender is always the instance of the type.
The following example illustrates an event handler with an appropriate name and parameters.
[Visual Basic]
Public Delegate Sub MouseEventHandler(sender As Object, e As MouseEventArgs)
[C#]
public delegate void MouseEventHandler(object sender, MouseEventArgs e);
The following example illustrates a correctly named event argument class.
[Visual Basic]
Public Class MouseEventArgs
Inherits EventArgs
Dim x As Integer
Dim y As Integer

Public Sub New MouseEventArgs(x As Integer, y As Integer)
me.x = x
me.y = y
End Sub

Public Property X As Integer
Get
Return x
End Get
End Property

Public Property Y As Integer
Get
Return y
End Get
End Property
End Class
[C#]
public class MouseEventArgs : EventArgs
{
int x;
int y;
public MouseEventArgs(int x, int y)
{ this.x = x; this.y = y; }
public int X { get { return x; } }
public int Y { get { return y; } }
}


Class Member Usage Guidelines

Property Usage Guidelines
Determine whether a property or a method is more appropriate for your needs. For details on choosing between properties and methods, see Properties vs. Methods.
Choose a name for your property based on the recommended Property Naming Guidelines.
When accessing a property using the set accessor, preserve the value of the property before you change it. This will ensure that data is not lost if the set accessor throws an exception.
Property State Issues
Allow properties to be set in any order. Properties should be stateless with respect to other properties. It is often the case that a particular feature of an object will not take effect until the developer specifies a particular set of properties, or until an object has a particular state. Until the object is in the correct state, the feature is not active. When the object is in the correct state, the feature automatically activates itself without requiring an explicit call. The semantics are the same regardless of the order in which the developer sets the property values or how the developer gets the object into the active state.
For example, a TextBox control might have two related properties: DataSource and DataField. DataSource specifies the table name, and DataField specifies the column name. Once both properties are specified, the control can automatically bind data from the table into the Text property of the control. The following code example illustrates properties that can be set in any order.
[Visual Basic]
Dim t As New TextBox()
t.DataSource = "Publishers"
t.DataField = "AuthorID"
' The data-binding feature is now active.
[C#]
TextBox t = new TextBox();
t.DataSource = "Publishers";
t.DataField = "AuthorID";
// The data-binding feature is now active.
You can set the DataSource and DataField properties in any order. Therefore, the preceding code is equivalent to the following.
[Visual Basic]
Dim t As New TextBox()
t.DataField = "AuthorID"
t.DataSource = "Publishers"
' The data-binding feature is now active.