We Care Through What We Share
  • 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

Words From Our Clients

0Years In Operation
0Loyal Clients
0Successful Projects

Tell Us About Your Project