General naming rules from .NET Framework Design Guidelines

The .NET Framework Design Guidelines is a set of guidelines provided by Microsoft to keep an unified programming model.

In this post I am going to summarize some of the main rules, but you should really read the entire document.

Capitalization Conventions

  • √ DO use PascalCasing for Namespace
  • √ DO use PascalCasing for Classes
  • √ DO use PascalCasing for Interfaces
  • √ DO use PascalCasing for Structs
  • √ DO use PascalCasing for Type
  • √ DO use PascalCasing for Interface
  • √ DO use PascalCasing for Method
  • √ DO use PascalCasing for Property
  • √ DO use PascalCasing for Event
  • √ DO use PascalCasing for static/readonly/const Fields
  • √ DO use PascalCasing for Enum names and values
  • √ DO use camelCasing for member variables
  • √ DO use camelCasing for parameters
  • √ DO use camelCasing for local variables

Naming Guidelines

  • √ DO name boolean variables with an affirmation (Visible; CanSeek…)
  • Optionally you can also prefix boolean variables with “Is”, “Can” or “Has”, but only where it adds value
  • √ DO choose readability over brevity
  • √ DO choose easily readable and meaningful names
  • √ DO use generic CLR type names (use int instead of Int32)
  • √ DO name a namespace after this template <Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
  • X DO NOT use underscores, hyphens, or any other nonalphanumeric characters (_, m_, s_, etc.)
  • X DO NOT use Hungarian notation
  • X DO NOT use abbreviations or contractions as part of identifier names

Prefixes and Suffixes

  • √ DO prefix Interfaces names with the letter “I”
  • √ DO prefix descriptive type parameters with the letter “T” (TSource…)
  • √ DO suffix custom attribute classes with “Attribute”
  • √ DO suffix event args classes with “EventArgs”
  • √ DO suffix custom exception classes with “Exception”
  • √ DO suffix set of elements classes with “Collection”
  • √ DO suffix custom stream classes with “Stream”

Class Structure

Usings statements should be inside the namespace.

The order of elements in classes should be:

  • Fields
  • Constructors
  • Properties
  • Events
  • Methods
  • Private interface implementations
  • Nested types

And each group should have their elements in alphabetical order.

See also

There is also a post from Brad Abrams that summarizes some of the guidelines.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s