Vous êtes sur la page 1sur 10

c  


c   

These are the industry-accepted standard naming conventions for C# and VB.NET programs. For
additional information, please see the MSDN help documentation and the book referenced
above. While individual naming conventions at organizations may vary (Microsoft only suggests
conventions for public and protected items), the list below is quickly becoming the de-facto
standard in the industry. Please note the absence of Hungarian Notation. These naming standards
should find their way into all of your .NET development, including ASP.NET Web applications,
WPF, Silverlight and Windows Forms applications.

Note that while this document predates the online and printed standards documentation from
Microsoft, everything below which indicates it is based on .NET library standards is consistent
with that documentation and Brad's book. In areas where Microsoft has not provided guidance
(Microsoft generally doesn't care what you do in private/non-exposed code. In fact, they aren't
even consistent in their internal code in the .NET framework), de facto standards have emerged,
and I have captured them here.

The "ux" naming convention for controls is something I have added and found to be helpful in
Windows Forms, but not so much in Silverlight and WPF. It is not based on any official
standards, but instead based upon a multitude of projects by my teams and others, as well as on-
line discussions on the topic. While I strongly recommend that you follow Microsoft guidelines
when present, I encourage you to try out the items marked as extensions below and see how they
work for you before committing to them.

   c     


   
     
 

Pascal Case, no underscores.


Use
CompanyName.TechnologyNa
me as root. If you don't have a Ä  
 
company, use your domain   
  
Namespaces     
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.
   
     
  Ä  
 
Assemblies   
  
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.
   
     
 

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   
Classes and  
should not have the same name
Structs  
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.
   
     
 

Follow class naming


Collection
conventions, but add Collection =

Classes
to the end of the name

Why: This convention is


consistent with the .NET
Framework and is easy to read.
Delegate     =
% & 
Classes      
 

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.
   
     
 

Follow class naming


Exception
conventions, but add Exception '   () 
Classes
to the end of the name

Why: This convention is


consistent with the .NET
Framework and is easy to read.
   
     
 

Follow class naming


Attribute
conventions, but add Attribute =% 'Ä %
Classes
to the end of the name

Why: This convention is


consistent with the .NET
Framework and is easy to read.
   
     
 

Follow class naming


conventions, but start the name
with "I" and capitalize the letter
following the "I"
Interfaces =
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.
   
     
 

Follow class naming


conventions. Do not add
"Enum" to the end of the  * !"%!+ $
Enumeration
enumeration name. If the
s Ä ,!" ! $
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.
   
     
 

Pascal Case, no underscores


except in the event handlers.
Try to avoid abbreviations.
Many programmers have a
nasty habit of overly
abbreviating everything. This
VB: %!%! "$
Functions should be discouraged. We're
and Subs not designing license plates or
C#: %!'! "$
being charged by the letter :)

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.
   
     
 
Properties VB: %!   #! !Ä!
and Public * 
Pascal Case, no underscores.
Member
Try to avoid abbreviations.
Variables C#: %!! 
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.
   
     
 

Camel Case. Try to avoid


abbreviations. Parameters must
VB: #+!  !Ä!
differ by more than case to be
Parameters
usable from case-insensitive
C#: +!!  
languages like Visual Basic
.NET.

Why: This convention is


consistent with the .NET
Framework and is easy to read.
    
   !"  
#  

Camel Case
Procedure- VB:  !  !Ä!
Level
Why: This convention is
Variables C#: !  !-
consistent with the .NET
Framework and is easy to read.
It also avoids naming collisions
with class-level variables (see
below)
    
   !"  
#  

Camel Case with Leading


Underscore. In VB.NET,
always indicate "Protected" or
Class-Level "Private", do not use "Dim".
VB:  ' !.  !Ä!
Private and Use of "m_" is discouraged, as
Protected is use of a variable name that
C#: ' !!.  !-
Variables 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.
"    $ 
 

%&&' 

Note that I still consider this


useful in many respects,
especially for intellisense
grouping, but have backed
away from using this in recent ã)ã! +)
projects, specifically Silverlight
and WPF. I still use an )/ 0!)  %0!
appropriate classification suffix )  *+  0!
such as Field or Label (but not )% 
 
Controls on an actual control type) so that I
Forms can differentiate between, say,
the last name field and the label
for it. !ã)ã! +)

 0!   %0!


Examples would be % 
 0!)  ' 
LastNameField,
LastNameLabel,
NextPageNavigation,
PreviousPageNavigation. The
classifications you pick will
need to make sense to you, and
also allow for signficiant
flexibility for the designer of
the UI to change the control
type in Xaml without you
having to change the name in
the storyboards (runtime
checked), code behind
(compile-time checked), and
control lookups in code behind
(runtime checked).

I backed away simply because


it didn't look right in generated
member variables in my
applications, or in the x:Name
properties in Xaml. It was a
code smell issue, albeit a minor
one.

Note also that in Silverlight and


WPF, I  name controls
which need to be named
because they are used in the
code behind or are referred to
from a storyboard or relative
binding. The name is the
primary contract between the
code and the visual design, and
you want to keep that contract
as small as possible.

Note that I have seen the "ux"


prefix in example code on the
net, and from Microsoft. Some
folks still find it useful. You'll
need to make that decision for
yourself.

I do not use the ux prefix when


working in XAML-based uI,
like Silverlight and WPF.

(
   
%&&%

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.
   
     
 

Same naming conventions as


public/private member
variables or procedure variables  
  %
 
of the same scope. If exposed
Constants  
 
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.

* Public class-level variables are universally frowned upon. It is considered to be a much better
practice to use property procedures (accessors and mutators) to provide read and/or write access
to a private member variable. If you must expose a member variable to other classes using
"Public", follow the property naming conventions, but don't complain if your guilty conscience
keeps you up at night ;-).

You Can find the standards for publicly exposed classes/properties etc at MSDN . If you want to
run a tool to validate your code for public standards and required practices, download FXCop or
use the analysis tools in Visual Studio.