General Naming Conventions

.NET Framework Developer's Guide

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.

Word Choice

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 Reference

Abbreviations and Acronyms

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.

Language-Specific Names

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.

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.

Other Resources

Design Guidelines for Developing Class Libraries

Guidelines for Names

Tags

: Add a tag

Community Content

Add new content

Annotations

Question

WFNet ... Dave Sexton | Edit | Show History

What does "in the rare cases when an identifier has no semantic meaning beyond its type" mean?

[Noelle Mallory - MSFT] Please post questions to the MSDN Forums at http://forums.microsoft.com/msdn. You will likely get a quicker response through the forum than through the Community Content.

[ FelixFrank ] (Answer) I read it as "As explained above, always do use names that carry semantic explanation such as 'int windowSize'. If none exists, do not use type names." The 'rare case' mentioned is that you retrieve some value from some function that will have no real world meaning. I can't really think of an example for this.

[I would have liked to post this as "new content" but this wouldn't work out. Sorry.]

[leogert] (Answer) Imagine you're writing a function that parses an int from a string. There is no semantic context to your string . It is just THE string, so it would be acceptable to just call it str rather than strInput or strToBeParsed.

[dave] Actually, using "str" would also contradict these guidelines because it is an unnecessary abbreviation. A better name would be "value", as suggested by the article; e.g., int ToInt32(string value). See, Convert.ToInt32: http://msdn.microsoft.com/en-us/library/sf1aw27b.aspx