.NET best practices?

Question

I know it is a broad topic but I'm interested in any of .NET's so-called best practices, though I'm looking for less obvious ones, unlike "use as instead of casting".
Let's see what interesting things I can learn from Stack Overflow users.

Answer 1

An interesting exercise is to run your code through a static analysis tool such as FxCop. It will bring up dozens of tips. Some may be appropriate for your application, some not. E.g. Internationalisation.

Answer 2

You may find these two books useful:

1. Effective C#
2. More effective C#

They are specific to C#, but you'll certainly learn many good ideas that apply to any .NET language.

Answer 3

Learn how to use Reflector. It will teach you more then you think.

Answer 4

For OO code you may want to check out the SOLID principles. However some argue they get in the way of a finished product.

Answer 5

• I find this tip very useful: Setting deployment retail="true" in the system.web tag in the web.config will force the debug flag to be "false". It will also force the custom error message page for the users and disable page output tracing. This is useful when the application is going to a production enviroment.

• Test Driven .Net is an excellent tool to run NUnit test inside Visual Studio.

Answer 6

This is a blog post about deploying web applications written in ASP.NET. I wrote it a couple of months ago. Could be interesting too.

Answer 7

Let's see what interesting things I can learn from Stack Overflow users.

This may not be exactly on target with "best practices" but certainly may be interesting to you. It looks like Stack Overflow has its share of practices, tips and tricks documented already.

For .NET:

• ASP.NET MVC
• Visual Studio
• Compact Framework

For C#:

• Hidden Features of C#
• Syntax Highlighting tricks

Answer 8

Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (2nd Edition) by Cwalina and Abrams explains the reasoning behind the FxCop rules, and much more. Not all of these may apply to your project, but you'll learn many best practices by reading this book. I refer to it often.

Answer 9

These aren't really .NET specific, but more general design:

One that immediately springs to mind (because I've seen this today and been ranting about it, and seen too many times before) is wrapping code with conditional checks for broken invariants, in order to avoid exceptions.

So, you end up with a system where some feature isn't working and you have no idea why this is the case, and have zero information on the original cause.

A great example I saw this week was one of our engineers had null reference checks around member variables which the UI framework (WPF) was responsible for assigning. These checks then avoided performing operations which would result in a null ref exception. So, in the event of this (catastrophic error) we have disabled functionality, a confused user and a pissed of support team.

So, fail fast, fail obviously (if possible) and record as much information as possible.

Another one of my favorite guiding principles is to minimize mutability. Where possible I prefer to design immutable classes. Immutability is becoming more fashionable now because of the multicore issue and the need to design for concurrency. I started using it though quite a while back having needed to simplify a system with complex graphs of shared state. I modelled the system on similar ideas to .NET's String and StringBuilder (it's sometimes handy to have a builder class to build up an immutable object particularly if it's fairly complex).

This was in fact my second version of this particular component. What I found was that designing to minimize mutability, and implementing immutable classes massively simplified the code base.

I've found that very few engineers consider this factor even when designing concurrent systems, and often end up with masses of extremely complex fragile code. I'm usually impressed in a way that they can get it to work! But, personally to me really good code should look simple.

Regards, Phil

Answer 10

I find people who ask what are the best practices for X, often need to stop and learn to think rather than just getting a magical list from someone. There is no magical list of 5 or 6 items, but rather many times a lot is common sense. Think about what you are attempting to achieve and how this code is executed in your environment.

Personally asking this sort of Q is an instant stop sign for me, because it shows the person has not tried to think for themselves and most likely never will. The most significant attribute in development work is the ability to problem solve and think a task logically. Learning syntax, libraries is just an exercise its not the be all and end all. Any developer can look at a new API and providing its not utter rubbish understand with some trial and error how it works.

Development is not a robotic task that one just follows a list, each and every class/component/insert building block here is different and requires thought and sensibleness.

Answer 11

This is not .NET specific, but the most important I think is the SOLID principle. Robert Martin (aka UncleBob) has a nice reference here. I will quote the most important section:

1. SRP The Single Responsibility Principle A class should have one, and only one, reason to change.
2. OCP The Open Closed Principle You should be able to extend a classes behavior, without modifying it.
3. LSP The Liskov Substitution Principle Derived classes must be substitutable for their base classes.
4. DIP The Dependency Inversion Principle Depend on abstractions, not on concretions.
5. ISP The Interface Segregation Principle Make fine grained interfaces that are client specific.

Steven Bohlen has made a short series of web casts about them at dimecasts.net.