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 |
2@107
|
 |
Do not suppress compiler warnings in the code |
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 |