DRS Data Services Limited
1 Danbury Court Linford Wood
Milton Keynes MK14 6LR England
Tel: +44(0)1908 666088
Fax: +44(0)1908 607668
[Link]
C# Coding Standards
C# Coding Standards
Document version 0.1
COPYRIGHT DRS DATA SERVICES LIMITED 2011. THIS DOCUMENT MAY NOT BE COPIED, REPRODUCED,
OR AMENDED IN ANY WAY, EITHER IN WHOLE OR IN PART, WITHOUT PRIOR PERMISSION.
31/03/2011 Development Best Practice
C# Coding Standards v1.1
Page 2 of 11
Amendment History
Version Date Description Author
0.1 28/05/2008 Initial version Adrian Kolek
1.0 09/06/2008 Published version Adrian Kolek
Updated to include guidelines for deployment
1.1 10/09/2009 of Program Database (PDB) files as discussed Adrian Kolek
in departmental Futures group.
31/03/2011 Development Best Practice
C# Coding Standards v1.1
Page 3 of 11
CONTENTS
Page
1. INTRODUCTION..............................................................................................................4
1.1 Purpose of the Document......................................................................................4
1.2 Microsoft Standards...............................................................................................4
2. NAMING CONVENTIONS................................................................................................5
2.1 General Recommendations...................................................................................5
2.2 Namespaces..........................................................................................................5
2.3 Classes..................................................................................................................5
2.4 Constants...............................................................................................................6
2.5 Public Methods and Properties..............................................................................6
2.6 Private and Protected Methods..............................................................................6
2.7 Private Fields.........................................................................................................6
2.8 Parameters and Local Variables............................................................................6
3. CODE LAYOUT CONVENTIONS....................................................................................7
3.1 Class Files..............................................................................................................7
3.2 Coding Guidelines..................................................................................................7
4. CODING BEST PRACTICES...........................................................................................9
4.1 Design....................................................................................................................9
4.2 Exception Handling..............................................................................................10
4.3 Implementation.....................................................................................................10
5. DEPLOYMENT...............................................................................................................11
5.1 Program Database (PDB) Files............................................................................11
31/03/2011 Development Best Practice
C# Coding Standards v1.1
Page 4 of 11
1. INTRODUCTION
1.1 Purpose of the Document
This document provides notes for developers working on .Net projects. It explains
the conventions to use when writing C# code.
The guidance in this document is intended to be applicable to any C# project.
1.2 Microsoft Standards
Microsoft provides a comprehensive set of standards for .Net development available
at:
[Link]
Code written for DRS projects should aim to comply with these standards.
31/03/2011 Development Best Practice
C# Coding Standards v1.1
Page 5 of 11
2. NAMING CONVENTIONS
2.1 General Recommendations
Ensure that class, property and method names are intuitive and self describing
Where a method or property returns a Boolean value, its name should imply the
meaning of a true of false result. This can often be achieved by including the
word “Is” or “Has” in the name. Examples of Boolean property names are
IsComplete and HasChildren.
Method and property names generally do not need to include the name of the
class to which they belong. For example, a Location class could have a property
called LocationName, however it would be better to call this property Name.
2.2 Namespaces
Namespaces should use Pascal casing, capitalising all the distinct words that make
up the name. Most projects should not require namespaces with more than three or
four elements. Namespaces should be constructed using the following standard
elements:
Company Name, Product, Area, Assembly
Examples of namespace names are:
[Link]
[Link]
2.3 Classes
Class names should use Pascal casing. Examples of class names are:
ValidationManager
ScannedFormProvider
ExportDataDirector
ScannedErrorCollection.
Class names should be singular.
31/03/2011 Development Best Practice
C# Coding Standards v1.1
Page 6 of 11
2.4 Constants
Constant names should be entirely in Pascal casing. Where a constant name
consists of several words, each word should begin with a capital letter. An example
of a constant name could be OperationCompletedMessage
2.5 Public Methods and Properties
Public methods and properties should use Pascal casing. Examples of method
names are Save, Validate, CreateFromTemplate. Examples of property names are
CompletedDate, ContactEmail and Name.
2.6 Private and Protected Methods
Private and protected methods should also use Pascal. Examples of method names
are Insert, SetAttributes and SetFieldData.
2.7 Private Fields
Private fields should use camel casing. Private fields should be prefixed with an
underscore to distinguish them from method parameters and local variables.
Examples of private field names are _locationId and _isValid.
Note: do not mark fields as protected. Rather mark them as private and access them
via a protected property.
2.8 Parameters and Local Variables
Method parameters and local variables should use camel casing. Examples of
parameter and local variable names are modeId and fileList.
31/03/2011 Development Best Practice
C# Coding Standards v1.1
Page 7 of 11
3. CODE LAYOUT CONVENTIONS
3.1 Class Files
Every class should be stored in its own .cs file. This file should have the same name
as the class, e.g. the WorkflowManager class should be stored in a file called
[Link].
Every class should be assigned to a project namespace.
3.2 Coding Guidelines
Place using directives at the top of the file.
Place constructors at the start of the class file
Indent code using tabs (Check Visual Studio Option – Tools/Options/Text
Editor/All Languages/Keep Tabs)
Align opening and closing curly brackets vertically, e.g.
public class MyClass
{
public MyClass(int myParameter)
{
if (myParameter > 0)
{
// do something
}
else
{
// do something else
}
}
}
Always use curly brackets around conditional and looping statements, even if the
condition/loop only applies to one line of code
31/03/2011 Development Best Practice
C# Coding Standards v1.1
Page 8 of 11
Use regions to divide the code. Visual Studio allows you to expand and contract
individual regions; this can help to navigate the source code files. For example:
public class MyClass : IMyClass
{
#region Fields
// Put fields here
#endregion
#region Constructors
// Put constructors here
#endregion
#region IMyClass Members
// Put IMyClass members here
#endregion
#region Members
// Put instance members here
#endregion
}
31/03/2011 Development Best Practice
C# Coding Standards v1.1
Page 9 of 11
4. CODING BEST PRACTICES
4.1 Design
Always program to an abstraction
Always work on the principal of “One object, one responsibility”
Use design patterns where appropriate to solve a problem. They promote proven
best practice throughout the industry and provide a common, consistent way for a
team to communicate (for example team leader states “implement this using the
command pattern” rather than explaining what is involved in order to implement
the functionality that the command pattern provides)
Warning: Never overuse design patterns. Designing an entire application around
them is guaranteed to add complication and that is not what is intended
Ensure that classes that by design should not be inherited from (e.g. Factories)
are marked as sealed
When deciding on the access modifier for a property or method, choose the most
restrictive modifier that will allow your code to work. Don’t make a method or
property public unless you know it will be used by other classes.
The internal access modifier can often be used instead of public. It allows
classes, methods and properties to be used within an assembly but prevents
access by code outside the assembly.
Default implementation for an object should ensure that all initialisation state is
passed into the constructor (as opposed to Property set members), private fields
are marked as readonly. Properties only expose the get member.
Where possible, initialise properties and class variables when declaring them.
This is particularly important for primitive data types (e.g. integers). For example:
int locationId = -1;
string locationName = “My Location”;
As far as possible, code using a class should not make assumptions about how
that class has been implemented. For example, if a class maintains a Hashtable,
code that uses the class should not attempt to modify the Hashtable directly;
instead it should use methods and properties of the class to achieve the desired
result.
31/03/2011 Development Best Practice
C# Coding Standards v1.1
Page 10 of 11
When an object that you are using exposes the IDisposable interface always
ensure that the Dispose method is called. This ensures that any resources being
held open by that object will be cleared up immediately. The recommended way
to do this (although it may not always be possible) is to enclose object access
within a using block:
using (MyManager manager = new MyManager())
{
......
[Link](); //use the manager object
......
} //The compiler will dispose the manager object now
4.2 Exception Handling
Only catch an Exception when you are going to do something with it. It is bad
practice to have a catch block that only re-throws the Exception that it has just
caught
Always catch the type of Exception that you intend to deal with
4.3 Implementation
Methods should aim to be a maximum of 20 lines in length. If a method is larger
than 20 lines a refactor of the method should be considered
A method should not have a cyclomatic complexity in excess of 10
A method should not have a nesting depth greater than 4
Generally a method must only have one exit point. The only exception to this
would be for specific performance reasons which must be approved on a case by
case basis
Comments must add value to the code and not just reiterate information that can
be clearly seen by reading the code within a method.
31/03/2011 Development Best Practice
C# Coding Standards v1.1
Page 11 of 11
5. DEPLOYMENT
5.1 Program Database (PDB) Files
Assembly’s across all solutions to be deployed into a production environment must be built
in “Release” configuration. Building solutions in “Release” configuration will not result in
Program Database (PDB) files being generated and as a rule Program Database (PDB) files
must not be deployed into a production environment.
However, as Program Database (PDB) files contain information that can be used when
debugging an application, on occasion it may be necessary to temporarily deploy these files
for the duration of a debugging task and for this reason and in these circumstances it is
considered to be acceptable.