Home Library Learn Downloads Support Community
Sign in | United States - English | |
6 out of 10 rated this helpful - Rate this topic

General Naming Conventions

.NET Framework 4

The general naming conventions discuss choosing the best names for the elements in your libraries. These guidelines apply to all identifiers. Later sections discuss naming specific elements such as namespaces or properties.

Do choose easily readable identifier names. For example, a property named HorizontalAlignment is more readable in English than AlignmentHorizontal.

Do favor readability over brevity. The property name CanScrollHorizontally is better than ScrollableX (an obscure reference to the X-axis).

Do not use underscores, hyphens, or any other nonalphanumeric characters.

Do not use Hungarian notation.

Hungarian notation is the practice of including a prefix in identifiers to encode some metadata about the parameter, such as the data type of the identifier.

Avoid using identifiers that conflict with keywords of widely used programming languages.

While CLS-compliant languages must provide a way to use keywords as regular words, best practices dictate that you do not force developers to know how to do this. For most programming languages, the language reference documentation contains a list of the keywords used by the languages. The following table provides links to the reference documentation for some widely used programming languages.

Language

Link

C#

C# Reference

C++

C++ Language Reference

Visual Basic

Visual Basic Language Reference

In general, you should not use abbreviations or acronyms. These make your names less readable. Similarly, it is difficult to know when it is safe to assume that an acronym is widely recognized.

For capitalization rules for abbreviations, see Capitalization Conventions.

Do not use abbreviations or contractions as parts of identifier names.

For example, use OnButtonClick rather than OnBtnClick.

Do not use any acronyms that are not widely accepted, and then only when necessary.

Do use semantically interesting names rather than language-specific keywords for type names. For example, GetLength is a better name than GetInt.

Do use a generic common language runtime (CLR) type name, rather than a language-specific name, in the rare cases when an identifier has no semantic meaning beyond its type.

For example, a method that converts data to Int16 should be named ToInt16, not ToShort because Short is the language-specific type name for Int16.

The following table shows the language-specific type names for common programming languages and the CLR counterpart.

C# type name

Visual Basic type name

JScript type name

Visual C++ type name

Ilasm.exe representation

CLR type name

sbyte

SByte

sByte

char

int8

SByte

byte

Byte

byte

unsigned char

unsigned int8

Byte

short

Short

short

short

int16

Int16

ushort

UInt16

ushort

unsigned short

unsigned int16

UInt16

int

Integer

int

int

int32

Int32

uint

UInt32

uint

unsigned int

unsigned int32

UInt32

long

Long

long

__int64

int64

Int64

ulong

UInt64

ulong

unsigned __int64

unsigned int64

UInt64

float

Single

float

float

float32

Single

double

Double

double

double

float64

Double

bool

Boolean

boolean

bool

bool

Boolean

char

Char

char

wchar_t

char

Char

string

String

string

String

string

String

object

Object

object

Object

object

Object

Do use a common name, such as value or item, rather than repeating the type name, in the rare cases when an identifier has no semantic meaning and the type of the parameter is not important.

Portions Copyright 2005 Microsoft Corporation. All rights reserved.

Portions Copyright Addison-Wesley Corporation. All rights reserved.

For more information on design guidelines, see the "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" book by Krzysztof Cwalina and Brad Abrams, published by Addison-Wesley, 2005.

Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
Readable names
About "it seems rather subjective to state that 'HorizontalAlignment' is easier to read than 'AlignmentHorizontal'"

It is not subjective, it's English syntax: the adjective comes before the noun.
History
About Hungarian notation
It was useful when there were relatively few data types (string, int, long, short, double, etc..)
Using it nowadays with .net means either using undigestible acronyms for components (would you believe that the prefix to "updbdMainPBar" means "UpdateProgressBarDelegate"?)  something  equally confusing like "o" for objects.
In short, the vast increase in the number of different "objects" has removed the usefulness of Hungarian notation (IMHO).

FYI, I started programming way, way back on a ZX81, so I guess that makes me an "old programmer" ;)
History
Hungarian Notation part 2
Intellisense is a great tool, but is not always available.  Eliminating the use of Hungarian notation because it is no longer necessary presumes that no developer will ever look at the source code using anything other than Visual Studio.

Even if I grant that Hungarian notation is no longer necessary given the improved tools available, there is  a vast difference between:

"Use of Hungarian notation is no longer required"

and

"Use of Hungarian notation is a bad coding practice"
History
Hungarian Notation
If the only reason your using hungarian is to allow future developers to know what type a variable is, simply hover over it with the mouse in VS.
History
Need more justification
What's wrong with Hungarian notation?  I agree that Hungarian notation is not *required* if the name of the variable is enough to distinguish its type  but nobody (until now, that is) has suggested that it is incorrect to use it. You'll have a hard time selling this, especially to experienced developers, without some better justification.

Along the same lines, it seems rather subjective to state that "HorizontalAlignment" is easier to read than "AlignmentHorizontal".  Even if I stipulate that it is, you lose grouping of similar variables when they are sorted alphabetically, say in an object browser.
History
Regarding underscores
Say how often do you mistakenly type propertyWithBackingField instead of PropertyWithBackingField? I did it quite often until I started using underscores to separate the fields from properties.
History
Naming convention for SQL Server
This is great guidelines, but I think is more complete if there is naming convention for SQL Server to.

Thanks
History