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.

Okay. But what does that look like? And, more importantly, how do I code my way out of it?

    PersonTypedDataSet GetPerson(Int64 personIdentifier);

This is your basic primitive obsession in action: use of primitive types as keys to a map (ERD, HashMap). This causes a flacid integration point. The parameter is an integral type - it has primitive rules regarding its domain and range. What means -1? Where do I get this magic number from? How do I remember what the number indicates? How do I get more information about this person number?

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.

This will NOT stop your application from terminating but at a minimum you can record the error in a log file for reference.

I grabbed this example from the MSDN documentation:
public static void Main() {
    AppDomain currentDomain = AppDomain.CurrentDomain;
    currentDomain.UnhandledException += new UnhandledExceptionEventHandler(MyHandler);
    try {
        throw new Exception("1");
    } catch (Exception e) {
        Console.WriteLine("Catch clause caught : " + e.Message);
    }
    throw new Exception("2");
    // Output:
    // Catch clause caught : 1
    // MyHandler caught : 2
}
static void MyHandler(object sender, UnhandledExceptionEventArgs args) {
    Exception e = (Exception) args.ExceptionObject;
    Console.WriteLine("MyHandler caught : " + e.Message);
}

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.