.NET Programming Standards and Naming Conventions

Standard Based Upon Microsoft .NET Library Standards

Pascal Case, no underscores. Use CompanyName.TechnologyName as root. If you don't
have a company, use your domain name or your own initials. Note that any acronyms
of three or more letters should be pascal case (Xml instead of XML) instead of all
caps.

Why: This convention is consistent with the .NET Framework and is easy to read.

Standard Based Upon Microsoft .NET Library Standards

If the assembly contains a single name space, or has an entire self-contained root
namespace, name the assembly the same name as the namespace.

Why: This convention is consistent with the .NET Framework and is easy to read.
More importantly, however, it keeps your assembly names and namespaces lined up,
making it really easy to figure out what is any particular assembly, and what assembly
you need to reference for any given class.

AppliedIS.TimeCard.BusinessRules.dll

IrritatedVowel.Controllers.dll

Standard Based Upon Microsoft .NET Library Standards

Pascal Case, no underscores or leading "C" or "cls". Classes may begin with an "I"
only if the letter following the I is not capitalized, otherwise it looks like an
Interface. Classes should not have the same name as the namespace in which they
reside. Any acronyms of three or more letters should be pascal case, not all caps.
Try to avoid abbreviations, and try to always use nouns.

Why: This convention is consistent with the .NET Framework and is easy to read.

Widget

InstanceManager

XmlDocument

MainForm

DocumentForm

HeaderControl

CustomerListDataSet (typed dataset)

Standard Based Upon Microsoft .NET Library Standards

Follow class naming conventions, but add Collection to the end of the name

Why: This convention is consistent with the .NET Framework and is easy to read.

Standard Based Upon Microsoft .NET Library Standards

Follow class naming conventions, but add Delegate to the end of the name

Why: This convention is consistent with the .NET Framework and is easy to read.

Standard Based Upon Microsoft .NET Library Standards

Follow class naming conventions, but add Exception to the end of the name

Why: This convention is consistent with the .NET Framework and is easy to read.

Standard Based Upon Microsoft .NET Library Standards

Follow class naming conventions, but add Attribute to the end of the name

Why: This convention is consistent with the .NET Framework and is easy to read.

Standard Based Upon Microsoft .NET Library Standards

Follow class naming conventions, but start the name with "I" and capitalize the
letter following the "I"

Why: This convention is consistent with the .NET Framework and is easy to read.
It also distinguishes classes from interfaces, where (unlike in VB6) are truly different
beings. This avoid name collisions as well, as it is quite common to have IFoo and
a class named Foo that implements IFoo.

Standard Based Upon Microsoft .NET Library Standards

Follow class naming conventions. Do not add "Enum" to the end of the enumeration
name. If the enumeration represents a set of bitwise flags, end the name with a
plural.

Why: This convention is consistent with the .NET Framework and is easy to read.

SearchOptions (bitwise flags)

AcceptRejectRule (normal enum)

Standard Based Upon Microsoft .NET Library Standards

Pascal Case, no underscores except in the event handlers. Try to avoid abbreviations.
Many programmers have a nasty habit of overly abbreviating everything. This should
be discouraged.

Functions and subs must differ by more than case to be usable from case-insensitive
languages like Visual Basic .NET

Why: This convention is consistent with the .NET Framework and is easy to read.

VB: Public Sub DoSomething(...)

C#: public void DoSomething(...)

Standard Based Upon Microsoft .NET Library Standards

Pascal Case, no underscores. Try to avoid abbreviations. Members must differ by
more than case to be usable from case-insensitive languages like Visual Basic .NET.

Why: This convention is consistent with the .NET Framework and is easy to read.

VB: Public Property RecordID As Integer

C#: public int RecordID

Standard Based Upon Microsoft .NET Library Standards

Camel Case. Try to avoid abbreviations. Parameters must differ by more than case
to be usable from case-insensitive languages like Visual Basic .NET.

Why: This convention is consistent with the .NET Framework and is easy to read.

VB: ByRef recordID As Integer

C#: ref int recordID

Standard Based Upon De facto Industry-Accepted Practices

Camel Case

Why: This convention is consistent with the .NET Framework and is easy to read.
It also avoids naming collisions with class-level variables (see below)

VB: Dim recordID As Integer

C#: int recordID ;

Standard Based Upon De facto Industry-Accepted Practices

Camel Case with Leading Underscore. In VB.NET, always indicate "Protected" or "Private",
do not use "Dim". Use of "m_" is discouraged, as is use of a variable name that
differs from the property by only case, especially with protected variables as that
violates compliance, and will make your life a pain if you program in VB.NET, as
you would have to name your members something different from the accessor/mutator
properties.

Of all the items here, the leading underscore is really the only controversial one.
I personally prefer it over straight underscore-less camel case for my private variables
so that I don't have to qualify variable names with "this." to distinguish from
parameters in constructors or elsewhere where I likely will have a naming collision.
With VB.NET's case insensitivity, this is even more important as your accessor properties
will usually have the same name as your private member variables except for the
underscore.

As far as m_ goes, it is really just about aesthetics. I (and many others) find
m_ ugly, as it looks like there is a hole in the variable name. It's almost offensive.
I used to use it in VB6 all the time, but that was only because variables could
not have a leading underscore. I couldn't be happier to see it go away.

Microsoft recommends against the m_ (and the straight _) even though they did both
in their code. Also, prefixing with a straight "m" is right out. Of course, since
they code mainly in C#, they can have private members that differ only in case from
the properties. VB folks have to do something else. Rather than try and come up
with language-by-language special cases, I recommend the leading underscore for
all languages that will support it.

If I want my class to be fully CLS-compliant, I could leave off the prefix on any
C# protected member variables. In practice, however, I never worry about this as
I keep all potentially protected member variables private, and supply protected
accessors and mutators instead.

Why: In a nutshell, this convention is simple (one character), easy to read (your
eye is not distracted by other leading characters), and successfully avoids naming
collisions with procedure-level variables and class-level properties.

VB: Private _recordID As Integer

C#: private int _recordID ;

An Extension to the Standards

In recent projects (since 2002 or so), I have taken to a single prefix for all my
UI controls. I typically use "ux" (I used to use "ui", but it wasn't set apart well
in intellisense). "ux" comes from my usual design abbreviations where it means "User
eXperience", which has also since become a popular acronym. I have found this to
be extremely helpful in that I get the desired grouping in the intellisense even
better than if I use "txt", "lbl" etc. It also allows you to change combo boxes
to text boxes etc. without having to change the names - something that happens often
during initial prototyping, or when programming using highly iterative agile/xp
methodologies.

Why: This convention avoids problems with changing control types (textboxes to drop-down
lists, or simple text box to some uber textbox, or text box to date picker, for
example), and groups the items together in intellisense. It is also much shorter
than most Hungarian conventions, and definitely shorter and less type-dependent
than appending the control type to the end of the variable name. I will use generic
suffixes which allow me enough freedom to change them around.

"ux" prefix

uxUserID, uxHeader, uxPatientDateOfBirth, uxSubmit

Standard Based Upon Microsoft .NET Library Standards

Same naming conventions as public/private member variables or procedure variables
of the same scope. If exposed publicly from a class, use PascalCase. If private
to a function/sub, use camelCase..

Do not use SCREAMING_CAPS

Why: This convention is consistent with the .NET Framework and is easy to read.
A sizable section of the Framework Design Guidelines is dedicated to why they chose
not to go the SCREAMING_CAPS route. Using SCREAMING_CAPS also exposes more of the
implementation than is necessary. Why should a consumer need to know if you have
an enum, or (perhaps because they are strings) a class exposing public constants?
In the end, you often want to treat them the same way, and black-box the implementation.
This convention satisfies that criteria.

SomeClass.SomePublicConstant

localConstant

_privateClassScopedConstant