Coding Guidelines

Design

• Don’t hide inherited members with the new keyword
• It should be possible to treat a derived object as if it were a base class object
• Do allow properties to be set in any order
• Don’t create a constructor that does not yield a fully initialized object
• Don’t return an arraylist or vector, use a generic array or list
• String and array properties should never return a null reference
• Provide a rich and meaningful exception message text
• Don’t swallow errors by catching non-specific exceptions
• Prefer throwing existing exceptions
• Do always check an event handler delegate for null
• Do use a protected virtual method to raise each event
• Do only implement casts that operate on the complete object
• Avoid casting to and from System.Object in code that uses generics
• Don’t add extension methods to the same namespace as the extended class
• Do evaluate the result of a LINQ expression before returning it

Maintainability

• Avoid using names that can be mistaken with other names
• Do name a source file to the class it contains
• Do limit the contents of a source code file to one class
• Don’t use "magic numbers"
• Do use var only when the type is very obvious
• Do initialize variables at the point of declaration, if possible
• Favor Object and Collection Initializers over separate statements
• Do use an enumeration instead of a list of strings if the list of values is finite
• Do use a block with all flow control keywords, even if it is empty
• Do code every if-else if statement with an else-part
• Avoid multiple return statements
• Prefer conditional statements instead of simple if-else constructs
• Do explicitly define the scope of a type or member
• Do implement the most complete overload of a method or constructor and call it from the other overloaded methods or constructors
• Avoid methods with more than 5 arguments
• Do always check the result of an as operation
• Use a method rather than a property when this is more appropriate
• Avoid write-only properties as they tend to be confusing. Consider using a method instead.

Usage

• Do use C# types instead of the types from the System namespace
• Don’t hardcode strings that are presented to end-users
• Do build with the highest warning level
• Avoid LINQ for simple expressions
• Do use Lambda expressions instead of delegates
• Do not use selection statements (if, switch) instead of a simple assignment or initialization (?, ??)

Naming

• Do use proper US English
• Don’t prefix member fields
• Do name an identifier according its meaning and not its type
• Do name classes, interfaces and value types with nouns, noun phrases or adjective phrases
• Don’t repeat the name of a class or enumeration in its members
• Do name methods using verb-object pair
• Do use a verb or verb phrase to name an event
• Do prefix an event handler with On
• Group extension methods in a class suffixed with Extensions
• Prefix interfaces with the letter I
• Suffix names of attributes with Attribute
• Use singular names for enumeration types
• Suffix exception classes with Exception
• Name DLL assemblies after their containing namespace
• Use Pascal casing for naming source files

Documentation

• Do use proper US English
• Do use XML tags for documenting types and members
• Do write XML documentation with the caller in mind
• Do write MSDN-style documentation
• Do write comments that explain the purpose (the why) of a code block

Layout

• Do write comments that explain the purpose of a code block
• Be reluctant with #regions
• Try not to exceed a line length longer than the width of the screen
• Do insert space after if, switch, while, for, foreach, catch, lock and using
• Do follow parentheses around any if, switch, while, for, foreach, catch, lock and using even when empty
• Do put parentheses on a new line

Empty lines

• Between members
• After the closing parentheses
• Between unrelated code blocks
• Around the #region keyword
• Between the using statements of the same company.

Casing

Reference: Philips Healthcare - C# Coding Standard