Académique Documents
Professionnel Documents
Culture Documents
VERSION 1.0
Page | 2
Introduction
This documents purpose is to establish standards and guidelines for applications written in C#. Adhering to
coding standards ensures a consistent code base for product life cycle management. Current and future
developers will have an easier time determining application structure and code meaning.
General
Tabs
Visual Studio should be set up to use spaces for tabs. Each tab should be 4 spaces.
TODO Items
Use the TODO keyword in comments on sections of code that need additional work done.
Statements
Each statement should start on its own line. Statements can be broken over multiple lines for readability.
Use Constants
Define constants or static readonly variables instead of magic numbers and strings.
Page | 3
Object Design
Create loosely coupled components. Provide interfaces that components can depend on rather than concrete
classes. Classes should have a single purpose.
Unused Code
Prefer removing code to commenting it out. You can retrieve it from SCM if it is needed later.
C#
Comments
For reference, see The Fine Art of Commenting
(http://www.icsharpcode.net/technotes/commenting20020413.pdf).
For documentation use XML comments preceded by three slashes.
Correct:
/// <summary>
/// Displays the About dialog
/// </summary>
Declaration
Use descriptive variable names. Do not use Hungarian Notation. Declare one variable per line.
Initialization
Initialize a variable as close to its declaration as possible.
Correct:
var time = DateTime.Now;
Page | 4
Naming
Properties
Properties and public members should be Pascal Case. Braces for properties should be on their own line
unless using Automatic Properties.
Correct:
public string AccountNumber { get; set; }
Or:
private string _accountNumber;
public string AccountNumber
{
get
{
return _accountNumber;
}
set
{
_accountNumber = value;
}
}
Fields
Fields and private members should be Camel Case with a leading underscore. Eg. _accountNumber
Page | 5
Namespaces
Namespaces should be Pascal Case. They should start with the organization name, followed by a period, then
followed by the application or library name, then additional labels separated by periods.
Correct:
CynergySystems.Commons
MyCompany.MyApp.Controls
MyCompany.Services.Tests
Method Signatures
Method names should be Pascal Case. Parameter names should be Camel Case. If a method requires many
parameters, break them into multiple lines.
Page | 6
Try/Catch Blocks
Each brace in a try block should be on its own line. Catch may be on its own line or on the same line as the
ending try brace.
Correct:
try
{
//...
}
catch (StyleNotFoundException)
{
// ...
}
try
{
//...
} catch (StyleNotFoundException ex)
{
// ...
}
Page | 7