What is good practice for understanding a system? What is the point of understanding a system? How and when does that understanding become outdated? These questions are relevant to system documentation - our topic. This article seeks to directly answer each of these in turn.

Primitive Obsession is a result of poor practices. Primitive Obsession is a byproduct the impedance mismatch between OOD and ERD. Primitive Obsession is a code smell indicating procedural design - encouraged by some heavyweight framework.

When is it okay to use fields? When are properties yagni? This was the topic of an email thread I was recently involved in. A friend of mine had determined to answer - once and for all - the overhead of using properties. The results of his testing indicated that property-usage has negligible impact on execution time. That in all but the most dire situations, property-usage is not a performance variable.

I actually looked into this about two years ago. I wrote a console app that benchmarked field/property access and mutation. The results were similar. But what I found useful was to compare the MSIL operations. The attached source is similar to that original code. It was compiled, tested, and disassembled under mono on Linux. You can run the binary as console app or nunit test fixture.

I found this reviewing the AppDomain class and think it's so awsome I had to write about it. You know how many times users get an unhandled error in a application and don't record the information. I am sure this happens to everyone. I think it's good practive for everyone to listent to this event and log unhandled exceptions.

Early in my software engineering career I was exposed to machine and assembly language programming. I find that fortuitous in that I was forced to be explicit; there are no cute constructs to fall back on when you're feeling lazy. Furthermore there is an implicitly enforced coding standard; I mean how many ways can you beautify mov cx, bx? Unfortunately the landscape gets increasingly muddied as you rise up the programming stack...

In higher-level languages you are abstracted sufficiently from machine operations - allowing you to focus on obtuse logic and visible components. And it is no surprise that there are many ways to jump not equals. With each representation comes advantages and disadvantages - and this is where considered coding practices are most valuable.