December Update of the Coding Guidelines for C# 3.0 and C# 4.0

I finally found some time to update the coding guidelines with some feedback I received since it’s original release in June this year. I’ve removed the following guidelines because I found that they were either very exotic or not general enough for most developers:

Avoid side-effects when throwing recoverable exceptions (AV1044)

Don’t make assumptions on the object’s state after raising an event (AV1050)

Explicitly define the scope of a type or member (AV1551) because it is a duplicate of AV1501.

I also noticed that the Design Guidelines section is getting bigger with each new version, so I split up that section into three smaller sections. And because of that, I had to renumber the guidelines in the AV1025-1100 range as well. So what about the new guidelines?

Well, these are new ones:

Use an interface to support multiple implementations, not a base class (AV1004)

Use an interface to decouple classes from each other (AV1005)

Avoid bidirectional dependencies (AV1020)

Classes should have state and behavior (AV1025)

Avoid mutual exclusive properties (AV1110)

Don’t expose stateful objects through static members (AV1125)

Use exceptions instead of return codes for reporting failures (AV1200)

Don’t use nested loops in a method (AV1532)

Consider abstracting an external dependency or 3rd party component (AV1580)

Share on

Leave a Comment

You May Also Enjoy

Transient vs non-transient exceptions
If I have to name the single biggest flaw in adopting Event Sourcing, it must be our decision to rely on the synchronous dispatching pipeline of NEventStore. It is based on the idea that every event will be processed by all projectors in a synchronous manner....

I thought we didn’t need OR/Ms anymore?
A common advantage of adopting Event Sourcing is that it solves the impedance mismatch between object oriented code and the relation database model. And because of that, Object/Relational Mappers (OR/Ms) have become obsolete. While I agree with the first st...

The characteristics of a great projection implementation
Over the course of the last two years I’ve written numerous articles on the good, the bad and the ugly of Event Sourcing as well as on our experiences building and maintaining a distributed enterprise-class based on this increasingly popula...

Over the last couple of months I’ve heard and read quite a few statements that say that Dependency Injection frameworks are bad things that you should avoid like the plague. In my opinion that’s just a result of rejecting something because it has been misused too long. Don’t get me wrong. I’ve be...