Dotnet framework design guidelines
There is an MSDN article a book on the subject but since it is more than 10 pages only few have read it.
Alas the Corefx team created a short list with stuff here: https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/framework-design-guidelines-digest.md
It is much easier to read
Comments about rules I have found but often not followed
“Do not postfix enums with Enum.” To be honest – I have often found it the best solution to postfix with Enum.
“Do not organise namespaces after company hierarchy.” Even though Conway’s law is a thing, a system should not keep the history of a changed organisation chart.
“Do not use List<T> on public methods.” List<T> is a complex beast. But using IEnumerable<T> might have some reiteration performance impact, that is when you have to loop through the same collection twice.
Other comments
“Carefully choose names for your types, methods, and parameters.” Naming things can be hard so take your time and discuss with your colleagues.
“Do not create mutable value types.” I totally agree. It is easier to debug imutable. Often when I track down a but I have only a (bad) call stack and the name of a public method and some source code. Then it is very important the code is easy to follow by hand.
“Do not throw
1 | Exception |
1 | SystemException |
“Members returning arrays should return copies of an internal master array.” I is good OOP practice to not publish internal stuff. Correction, it is cruical OOP practice to not expose the innards of a class.
Other other comments
“Prefer classes over interfaces.” Why? Context please.
IMO the linked article forgot to mention that public methods should not have optional parameters as they are compiled into the caller and not callee.
Avoid public as any change to them might break the API. Unfortunately Visual studio defaults new classes (and methods?) to public so I see them everywhere.
Tags: framework design