A consistent naming pattern is one of the most important elements of predictability and discoverability in a managed class library. This topic provides naming guidelines for the .NET Framework types. For each type, you should also take note of some general rules with respect to capitalization styles, case sensitivity and word choice.

 

For full details refer: http://msdn.microsoft.com/en-us/library/xzf533w0(VS.71).aspx

 

Capitalization Styles

 

1.       Pascal case

The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. You can use Pascal case for identifiers of three or more characters.

For example:   BackColor

 

2.       Camel case

The first letter of an identifier is lowercase and the first letter of each subsequent concatenated word is capitalized.

For example: backColor

 

3.       Uppercase

All letters in the identifier are capitalized. Use this convention only for identifiers that consist of two or fewer letters.

For example:   System.IO, System.Web.UI

 

 

Identifier	Case	Example	Use Hungarian ?	Use underscore “_” ?
Namespace	Pascal	System.Drawing Microsoft.Media.Design	No	No
Interface	Pascal	IDisposable	No	Avoid
		Note   Always begins with the prefix I.
Class	Pascal	AppDomain	No	No
Property	Pascal	BackColor	No	No
Method	Pascal	ToString		Avoid
Parameter	Camel	typeName	No	No
Event	Pascal	ValueChange	No	Don’t use in Event delegates
Enum type	Pascal	ErrorLevel	No	Avoid
Enum values	Pascal	FatalError	No	No
Read-only Static field	Pascal	RedValue	No	No
Protected instance field	Camel	redValue	No	No
Public instance field	Pascal	RedValue	No	No
Exception class	Pascal	WebException	No	No
		Note   Always ends with the suffix Exception.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

When using acronyms, use Pascal case or camel case for acronyms more than two characters long.

For example, use HtmlButton or htmlButton instead of HTML. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io.

 

Hungarian notation

 

Hungarian notation is a naming convention in computer programming, in which the name of a variable indicates its type or intended use. There are two types of Hungarian notation:

1. Systems Hungarian notation
2. Apps Hungarian notation.

 

It is not recommended to use Hungarian Notation in .Net languages.

 

In Hungarian notation, a variable name starts with one or more lower-case letters which are mnemonics for the type or purpose of that variable, followed by whatever the name the programmer has chosen; this last part is sometimes distinguished as the given name. The first character of the given name can be capitalised to separate it from the type indicators Otherwise the case of this character denotes scope.

 

In Systems Hungarian notation, the prefix encodes the actual data type of the variable. For example:

 

• iAccountNum : variable is a integer ("i");
• arru8NumberList : variable is an array of unsigned 8-bit integers ("arru8");
• szName : variable is a zero-terminated string ("sz"); this was one of Simonyi's original suggested prefixes.

 

Apps Hungarian notation doesn't encode the actual data type, but rather, it gives a hint as to what the variable's purpose is, or what it represents.

 

• rwPosition : variable represents a row ("rw");
• usName : variable represents an unsafe string ("us"), which needs to be "sanitized" before it is used (e.g. see code injection and cross-site scripting for examples of attacks that can be caused by using raw user input)
• strName : Variable represents a string ("str") containing the name, but does not specify how that string is implemented.

 

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]

 

1. Do not use character underscore ‘_”

 

 

For example:

Microsoft.Media

 

Interface Naming Guidelines

 

1. Prefix interface names with the letter I, to indicate that the type is an interface.
2. 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.

1. Use abbreviations sparingly.
2. 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.

 

The following are examples of correctly named interfaces.

[Visual Basic]

Public Interface IServiceProvider

Public Interface IFormatable

 

[C#]

public interface IServiceProvider

public interface IFormatable

 

Class Naming Guidelines

 

1. Do not use a type prefix, such as C for class, on a class name.

For example, use the class name FileStream rather than CFileStream.

1. Do not use character underscore ‘_”
2. Use a noun or noun phrase to name a class.
3. Use abbreviations sparingly.
4. Occasionally, it is necessary to provide a class name that begins with the letter I, even though the class is not an interface. This is appropriate as long as I is the first letter of an entire word that is a part of the class name. For example, the class name IdentityStore is appropriate.
5. Where appropriate, use a compound word to name a derived class. The second part of the derived class's name should be the name of the base class.

For example, ApplicationException is an appropriate name for a class derived from a class named Exception, because ApplicationException is a kind of Exception.

 

Use reasonable judgment in applying this rule.

For example, Button is an appropriate name for a class derived from Control. Although a button is a kind of control, making Control a part of the class name would lengthen the name unnecessarily.

 

The following are examples of correctly named classes.

[Visual Basic]

Public Class FileStream

Public Class Button

Public Class String

 

[C#]

public class FileStream

public class Button

public class String

 

Property Naming Guidelines

 

The following rules outline the naming guidelines for properties:

 

1. Use a noun or noun phrase to name properties.
2. Use Pascal case.
3. Do not use Hungarian notation.

For example , do not use names like strID, or intUserID

1. 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.
2. Property which returns Boolean value should start with prefix “is” or “has”
3. Property name should be different then global variable names.
4. Do not use character underscore ‘_”

 

 

 

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.

   }

}

 

Method Naming Guidelines

 

The following rules outline the naming guidelines for methods:

 

1. Use verbs or verb phrases to name methods.
2. Avoid use of character underscore ‘_”
3. Use Pascal case.
4. Method name should reflect either activity or behavior.

For example, RemoveAt, SaveData

1. Method which returns Boolean value should start with prefix “is” or “has”

 

The following are examples of correctly named methods.

RemoveAll()

GetCharArray()

Invoke()

 

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:

 

1. 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.
2. 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.
3. 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.
4. Do not prefix parameter names with Hungarian type notation.
5. Avoid use of character underscore ‘_”

 

 

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)

 

 

Static Field Naming Guidelines

 

The following rules outline the naming guidelines for static fields:

 

1. Use nouns, noun phrases, or abbreviations of nouns to name static fields.
2. Use Pascal case.
3. Do not use a Hungarian notation prefix on static field names.
4. It is recommended that you use static properties instead of public static fields whenever possible.

 

Sample code in vb.net shows applied best practices

 

Namespace AT.Common.UserControls.Template

 

      Public Class EmailProcessor

 

            Private _moduleID As Integer

            Private _bodyHtml As String

            Private _isSent As Boolean

 

            Public Property ModuleID() As Integer

                  Get

                        Return _moduleID

                  End Get

                  Set(ByVal value As Integer)

                        _moduleID = value

                  End Set

            End Property

 

            Public Property BodyHtml() As String

                  Get

                        Return _bodyHtml

                  End Get

                  Set(ByVal value As String)

                        _bodyHtml = value

                  End Set

            End Property

 

            Public Property IsSent() As Boolean

                  Get

                        Return _isSent

                  End Get

                  Set(ByVal value As Boolean)

                        _isSent = value

                  End Set

            End Property

 

            Public Sub CopyRequiredProperties(ByVal moduleNfo As DotNetNuke.Entities.Modules.ModuleInfo)

                  Me.ModuleID = moduleNfo.ModuleID

            End Sub

 

            Public Function HasContent() As Boolean

                  Return BodyHtml.Trim().Lenght > 0

        End Function

 

    End Class

 

End Namespace