C# Coding Standard

Coding Rules

Name	Checked	Synopsis
2@102		Every time a recommendation is not followed, this must have a good reason
2@105		Do not mix code from different providers in one file
2@106		Do not put more than one major class in one source file
3@101		Use US-English for naming identifiers
3@102		Use Pascal and Camel casing for naming identifiers
3@103		Do not use Hungarian notation or add any other type identification to identifiers
3@104		Do not prefix member fields
3@105		Do not use casing to differentiate identifiers
3@106		Use abbreviations with care
3@107		Do not use an underscore in identifiers
3@108		Name an identifier according to its meaning and not its type
3@109		Name namespaces according to a well-defined pattern
3@110		Do not add a suffix to a `class` or `struct` name
3@111		Use a noun or a noun phrase to name a `class` or `struct`
3@112		Abbreviations with more than two letters should be cased as words
3@113		Prefix interfaces with the letter `I`
3@120		Use similar names for the default implementation of an interface
3@122		Suffix names of attributes with `Attribute`
3@201		Do not add an `enum` suffix to an enumeration type
3@202		Use singular names for enumeration types
3@203		Use a plural name for enumerations representing bitfields
3@204		Do not use letters that can be mistaken for digits, and vice versa
3@301		Add `EventHandler` to delegates related to events
3@302		Add `Callback` to delegates related to callback methods
3@303		Do not add a `Callback` or similar suffix to callback methods
3@304		Use a verb (gerund) for naming an event
3@305		Do not add an `Event` suffix (or any other type-related suffix) to the name of an event
3@306		Use an -`ing` and -`ed` form to express pre-events and post-events
3@307		Prefix an event handling method with `On`
3@401		Suffix exception classes with `Exception`
3@402		Do not add code-archive related prefixes to identifiers
3@501		Name DLL assemblies after their containing namespace
3@502		Do not add MR building block prefixes to source files
3@503		Use Pascal casing for naming source files
3@504		Name the source file to the main class
3@505		Only use the `this.` construction to avoid a name clash
3@510		Use descriptive names for generic type parameters
3@511		Give a thread a useful name
4@101		Each file shall contain a header block
4@103		Use // for comments
4@105		All comments shall be written in English
4@106		Use XML tags for documenting types and members
4@110		Use `#region` to group non-public members
4@111		Don't comment out code
5@101		Declare and initialize variables close to where they are used
5@102		If possible, initialize variables at the point of declaration
5@105		Use a `const` field to define constant values
5@106		Use a `public static readonly` field to define predefined object instances
5@107		Set a reference field to `null` to tell the garbage collector that the object is no longer needed
5@108		Do not re-declare a visible name in a nested scope
5@111		Avoid implementing a finalizer
5@112		Provide a method that will cause the finalizer not to be called
5@113		Implement `IDisposable` if a class uses unmanaged resources, owns disposable objects or subscribes to other objects
5@114		Do not access any reference type members in the finalizer
5@116		Always document when a member returns a copy of a reference type or array
5@117		Properties, methods and arguments representing strings or collections should never be null
5@118		A virtual method may only be called if an object is fully constructed
5@119		Return interfaces to unchangeable collections
5@120		Avoid using named arguments
5@121		Don't use "using" variables outside the scope of the "using" statement
5@122		Avoid empty finalizers
6@101		Do not change a loop variable inside a `for` loop block
6@102		Update loop variables close to where the loop condition is specified
6@103		All flow control primitives (if, else, while, for, do, switch) shall be followed by a block, even if it is empty
6@105		Ensure `switch` statements are exhaustive
6@106		Finish every `if-else-if` statement with an `else` part
6@109		Don't return a function at an unexpected location
6@112		Do not make explicit comparisons to `true` or `false`
6@115		Do not access a modified object more than once in an expression
6@118		Do not use selection statements `(if, switch)` instead of a simple assignment or initialization
6@119		Avoid locking on a public type
6@120		Avoid conditions with double negatives
6@121		Don't use parameters as temporary variables
6@191		Do not dereference null
6@201		The cyclomatic complexity of a method should not exceed its configured maximum.
7@101		Declare all fields (data members) `private`
7@102		Prevent instantiation of a class if it contains only `static` members
7@105		Explicitly define a `protected` constructor on an `abstract` base class
7@106		Make all types internal by default
7@107		Limit the contents of a source code file to one type
7@108		Use using statements instead of fully qualified type names
7@201		Selection statements (`if-else` and `switch`) should be used when the control flow depends on an object's value; dynamic binding should be used when the control flow depends on the object's type
7@301		All variants of an overloaded method shall be used for the same purpose and have similar behavior
7@303		If you must provide the ability to override a method, make only the most complete overload virtual and define the other operations in terms of it
7@304		Only use optional arguments to replace overloads
7@401		Specify methods using preconditions, postconditions, exceptions; specify classes using invariants
7@402		Use code to describe preconditions, postconditions, exceptions, and class invariants
7@403		It shall be possible to use a reference to an object of a derived class wherever a reference to that object's base class object is used
7@404		Don't hide inherited members with the new keyword
7@501		Do not overload any 'modifying' operators on a `class` type
7@502		Do not modify the value of any of the operands in the implementation of an overloaded operator
7@503		If you implement one of `operator==()`, the `Equals` method or `GetHashCode()`, implement all three
7@504		Use a `struct` when value semantics are desired
7@520		Override the `GetHashCode` method whenever you override the `Equals` method.
7@521		Override the `Equals` method whenever you implement the `==` operator, and make them do the same thing
7@522		Override the `Equals` method any time you implement the `IComparable` Interface
7@523		Do not throw exceptions from the `Equals` or `GetHashCode` methods or the equality operator (`==`)
7@525		Override the `Equals` method on value types.
7@526		Reference types should NOT override the equality operators ('`==`' and '`!=`')
7@530		Implement operator overloading for the equality (`==`), not equal (`!=`), less than (`<`), and greater than (`>`) operators when you implement `IComparable`
7@531		Overload the equality operator (`==`), when you overload the addition (`+`) operator and/or subtraction (`-`) operator
7@532		Implement all relational operators (`<`, `<=`, `>`, `>=`) if you implement any
7@533		Do NOT use the `Equals` method to compare diffferent value types, but use the equality operators instead.
7@601		Allow properties to be set in any order
7@602		Use a property rather than a method when the member is a logical data member
7@603		Use a method rather than a property when this is more appropriate
7@604		Do not create a constructor that does not yield a fully initialized object
7@608		Use pattern matching instead of the "as" keyword
7@609		Use the correct way of casting
7@610		Use generic constraints if applicable
7@610		Use explicit interface implementation only to prevent name-clashing or to support optional interfaces
7@611		Use generic constraints if applicable
7@700		Do not ignore method results
8@101		Only throw exceptions in exceptional situations
8@102		Do not throw exceptions from unexpected locations
8@103		Only re-throw exceptions when you want to specialize the exception
8@104		Document the exceptions that are explicitly thrown by a method or a property
8@105		Always log that an exception is thrown
8@106		Allow callers to prevent exceptions by providing a method or property that returns the object's state
8@107		Use standard exceptions
8@108		Throw informational exceptions
8@109		Throw the most specific exception possible
8@110		Do not silently ignore exceptions
8@111		Throw exceptions rather than returning some kind of status value
8@201		Derive custom exceptions from `ApplicationException`
8@202		Provide common constructors for custom exceptions
8@203		Avoid side-effects when throwing recoverable exceptions
8@204		Do not throw an exception from inside an exception constructor
9@101		Do not make assumptions on the object's state after raising an event
9@102		Always document from which thread an event handler is called
9@103		Raise events through a protected virtual method
9@104		Use the sender/arguments signature for event handlers
9@105		Implement add/remove accessors if the number of handlers for an event must be limited
9@106		Consider providing property-changed events
9@107		Consider an `interface` instead of a `delegate`
9@108		Use delegate inference instead of explicit delegate instantiation when possible
9@110		Each subscribe must have a corresponding unsubscribe
9@111		Use generic event handler instances
9@112		Prevent passing null values for sender/object to event handler (for instance-based events)
9@113		Always check an event handler delegate for null
9@114		Do not use return values of callbacks in events
10@201		Use an `enum` to strongly type parameters, properties, and return types
10@202		Use the default type `Int32` as the underlying type of an `enum` unless there is a reason to use `Int64`
10@203		Use the `[Flags]` attribute on an `enum` if a bitwise operation is to be performed on the numeric values
10@301		Do not use 'magic numbers'
10@401		Floating point values shall not be compared using the `==` nor the `!=` operators nor the `Equals` method.
10@403		Do not cast types where a loss of precision is possible
10@404		Only implement casts that operate on the complete object
10@405		Do not generate a semantically different value with a cast
10@406		When using composite formatting, do supply all objects referenced in the format string
10@407		When using composite formatting, do not supply any object unless it is referenced in the format string
10@501		Only use var when the type is very obvious
11@101		Do not mix coding styles within a group of closely related classes or within a module
11@403		The `public`, `protected`, and `private` sections of a `class` or `struct` shall be declared in that order
11@407		Write unary, increment, decrement, function call, subscript, and access operators together with their operands; insert spaces around all other operators
11@408		Always write the left parentheses directly after a method/function name
11@409		Use spaces instead of tabs
11@411		Do not create overly long source lines
11@412		Put case labels on a separate line
11@413		Do use spaces before and after binary operators for readability
12@101		Avoid boxing and unboxing of value types
12@101		Do not use ToUpper() or ToLower() for case insensitive string comparison
12@102		Do not use `ToLower`/`ToUpper` for case insensitive string comparison
12@103		Consider using `Any()` to determine whether an `IEnumerable` is empty
12@103		Consider using `Any()` to determine whether an `IEnumerable` is empty
12@104		Test for empty strings using string length or String.IsNullOrEmpty
12@105		Use the evaluation order of && (and operator) and \|\| (or operator) to increase performance
12@106		Use List<> instead of ArrayList especially for value types