DotNet Framework design GuildeLines

https://msdn.microsoft.com/en-us/library/ms229043(v=vs.110).aspx

https://github.com/Azure/DotNetty/wiki/C%23-Coding-Style

1. Capitalization rules

1.1. Namespace, type. Interface, method, property, event, field, enum – PascalCasing.

1.2. Parameter, local variable - camelCasing.

1.3. Do not rely on capitalization alone.

2. Naming

2.1. Prefer readability over brevity.

2.2. Do not use underscores, hyphens, and other non-alphanumeric chars.

2.3. Do not use Hungarian notation

2.4. Avoid common keywords

2.5. Do not use abbreviations and acronyms

2.6. Existing API

2.6.1. Use same way of naming when extending api

2.6.2. Use suffix rather than prefix to add a newer version, or better: consider naming new function

2.7. Assemblies

2.7.1. Large chunk of functionality

2.7.2. Naming pattern: < Company>.< Component>.dll

2.8. Namespaces

2.8.1. < Company>.(< Product> |< Technology>)[.< Feature> ][.< Subnamespace> ]

2.8.2. Product name should be stable, version-independent.

2.8.3. Do not use organization hierarchies as namespace name

2.8.4. Do not use same name of namespace and type in that namespace

2.8.5. Avoid common namespace names Element, Node, Log, Message

2.8.6. Use unique namespace and type names throughout solution

2.9. Classes

2.9.1. Use Nouns

2.9.2. Use adjectives for interface names

2.9.3. Donot use prefixes for classname

2.9.4. Interfaces should start with I

2.9.5. Add suffixes for derived classes:..Collection,..Exception,..Dictionary,..EventHandler

2.10.Enums

2.10.1. Singular words

2.11.Methods

2.11.1. Verbs or Phrases

2.12.Properties

2.12.1. Use nouns or phrases

2.12.2. Do not use Get, or verbs

2.12.3. Boolean use Is, Can Has, if it has value

2.12.4. Consider giving names as types (Public Color Color)

2.13.Fields

2.13.1. Noun, phrase, adjective

2.13.2. Don’t use prefix

2.14.Parameters

2.14.1. Use descriptive name

2.14.2. Use meaning instead of type

2.14.3. Use left and right for binary operators

3. Class design

3.1. Ensure class is a well-defined set of members, not just collection of unrelated functionality

3.2. Structs vs classes

3.2.1. Structs are cheaper in memory than classes

3.2.2. Structs should be defined when

3.2.2.1. It represents a single value

3.2.2.2. It has instance size under 16 bytes

3.2.2.3. It is immutable

3.2.2.4. It will not have to be casted frequently

3.3. Static classes

3.3.1. Use them rarely

3.3.2. Design them sealed

3.3.3. Do not use static class as a heap of misc functionality

3.4. Interfaces design common API for set of types that differ in functionality

3.4.1. Do provide at leas one type as an implementation of interface

3.4.2. Do not add members to previously-shipped interfaces.

3.5. Structs

3.5.1. Structs are copied on assignment, not referenced as classes.

3.5.2. Ensure that null or 0 values of members are valid, as it causes problems with arrays of structs

3.5.3. Implement IEquattable

4. Member design

4.1. Parameters should be descriptive

4.2. Overloads should have consistent naming

4.3. Allow null to be passed to optional arguments

4.4. Use overloading instead of methods with default arguments

5. Constructors

5.1. Provide simple default constructors

5.2. Provide constructor overload with setting instance properties. Use consistent naming

5.3. Do minimal work in constructor

5.4. Declare public default constructor if it is required.

6. Properties

6.1. Get-only properties are OK. Set-only are not.

6.2. Provide stable defaults for properties.

6.3. Properties should be available to set in any order.

6.4. Preserve a previous value if the setter throws.

6.5. Getters should not throw

7. Fields

7.1. Use constants

7.2. Use static readonly

7.3. Do not provide public or protected fields, use properties instead.

8. Parameters

8.1. Use least derived parameter type (generic preferably).

8.2. Do not use reserved parameters. Add overload instead.

8.3. Do not use pointers or multi-dimensional arrays as parameters

8.4. Use enums instead of Booleans if not sure about options

8.5. Use consistent parameter naming.

9. Exceptions

9.1. Do not return error codes

9.2. Use exceptions

9.3. Do not use exceptions for normal flow control

9.4. Do document all exceptions

9.5. Do not throw System.Exception or System.SystemException, StackOverFlowException and do not catch them.

9.6. Do not derive from ApplicationException.

9.7. Use ArgumentException, ArgumentNullException, ArgumentOutOfRange exception. Use paramName and value in these.

9.8. NullReferenceException, IndexOutOfRangeException, AccessViolationException are almost always is a bug in your code, so don’t throw them.

9.9. Consider performance issues on throwing. Exceptions aren’t cheap.

10. Collections

10.1.Use collections instead of arrays

10.2.Use array of arrays instead of multi-dimensional array

10.3.Do not use List< T>, Hashtable< T>, Dictionary< Tkey, Tvalue> in public API.

10.4.In low-level API use arrays over collections because of performance increase

10.5.Use..Dictionary,..Collection suffix for custom collections

11. C# Coding Conventions

11.1.Use curly braces on new line (Allman style).

11.2.Use 4-char space instead of tabs.

11.3.Long namespace directives should be moved on next line.

11.4.One statement per line, one declaration per line.

11.5.One blank line between method and property definition.

11.6.Use () for making calculation order apparent.

11.7.Use only public properties, fields should be private

11.8.Always use this. When appropriate.

11.9.Commenting

11.9.1. Comments on separate line, not at the end of code line

11.9.2. Comments precede with space

11.9.3. Comments end with period

11.9.4. Comments start with uppercase letter

11.9.5. Do not create formatted blocks of * around comments

11.10. Strings

11.10.1. Use string builder for concatenation

11.10.2. Use implicit typing (var) for local variables when it is clear what type it is.

11.10.3. Use implicit typing (var) in foreach