Write it Right

Shakespeare's Casear siad "cowards die many times before their deaths, the valiant never taste of death but once."


Write code badly and you will taste it again and again and again. (and it does not improve with subsequent re-heatings)


"Write It Right" and you only need to see it again when something relevant changes.


It may take twice as long to "Write It Right", but if you figure out how much time gets spent fixing bad broken code one "stoopid" at a time, twice as long seems like a bargain.


Add in secondary costs, Building Releases, Damage to Customer Confidence, Direct Cost of Bugs, and WIR seems so obvious it hardly needs to be said.


Yet, it would appear, it needs to be said again and again and again.


WIR

Know what is executing when and where...

If we run this test, it throws an uncaught exception from the thread pool. Uncaught exceptions from the thread pool will crash your app.

The key to this is that the lambda is not executed here and now. The Lambda is passed to the thread pool.
The thread pool executes it, but only after we have set our classWithFunction member variable to null.

 class ClassWithFunction  
 {  
   public void fn()  
   {  
     System.Console.WriteLine("Hello World");  
   }  
 }  
   
 ClassWithFunction classWithFunction = new ClassWithFunction();  
   
   
 [Test]  
 public void testThreadPool()  
 {  
   ThreadPool.QueueUserWorkItem(state => classWithFunction.fn());  
   
   classWithFunction = null;  
   
   Thread.Sleep(2000);  
 }  
   

If you consider the Lambda in terms of a function, it all becomes a whole lot clearer. By the time ThreadPoolFunction is called, classWithFunction is null.
This is referred to as a modified closure. The Lambda does not get a copy of our variable, it actually uses our variable in place.

 class ClassWithFunction  
 {  
   public void fn()  
   {  
     System.Console.WriteLine("Hello World");  
   }  
 }  
   
 ClassWithFunction classWithFunction = new ClassWithFunction();  
   
 [Test]  
 public void testThreadPool()  
 {  
   ThreadPool.QueueUserWorkItem(ThreadPoolFunction);  
   
   classWithFunction = null;  
   
   Thread.Sleep(2000);  
 }  
   
 private void ThreadPoolFunction(object state)  
 {  
    classWithFunction.fn();  
 }  

And if you look closely, you will see that this IS different and it works quite nicely. Of course, the downside of this as a solution is that someone will surely come along and remove the "unnecessary" temporary variable.

 [Test]  
 public void testThreadPool()  
 {  
   ClassWithFunction tempClassWithFunction = classWithFunction;  
   ThreadPool.QueueUserWorkItem(state => tempClassWithFunction.fn());  
   
   classWithFunction = null;  
   
   Thread.Sleep(2000);  
 }  

Perhaps it would be better to move up to .net 4 and use the Parallel Task Library instead.

Important / Urgent

From the good old Important / Urgent time management graph, we can see how Code Quality is not "Urgent" but the fallout of poor code, Bugs, are both Important and Urgent.

If we ignore Code Quality, we borrow against future effort and build up a technical debt. We end up with more bugs which are important/urgent, which means less time for Code Quality, which means more bugs.....

Rinse, Repeat, buy an "Inside I'm Screaming" teeshirt.

	Not Urgent	Urgent
Important	Code Quality	Fix Bugs
Not important	Fix "trivial" bugs	Coffee

Clearly, this is an incomplete table, but you get the idea.

Tragic Heroes of Design

I doubt you could find anyone who has studied literature who could not talk about the "Tragic Hero". It has been a pattern in literature since Aristotle's time. Many of the aspects are repeated again and again in plays, stories and films. This is an early Design Pattern.

How is it then that when I interview people for Software Engineering roles, some have barely heard of design patterns. Many can only name Singleton, and few can simply state the basic idea that these Design Patterns are simply well known ways of solving problems. They are solutions that work well, are easy to maintain and have good properties in terms of specific criteria, which may be, for example, performance, dependencies or maintainability.

I'd expect any engineer with a lot of experience to at least know about a façade and a decorator, and be able to explain why a factory class is more than just a "place to put constructors together". I'd expect them to know what a Strategy Pattern was, or a Command Pattern.

These are not the "current fad", they are high level, well known ways of doing things. They are not a magic bullet, they are simple basic knowledge.

Assuming that you can read and write to a basic standard, how would you begin to compare Hamlet and King Lear without an understanding of "The Tragic Hero" as a starting point.

Why are people dismissive of the whole idea?

Unit Tests, Code Quality and Legacy Code

Some days you start adding unit tests to legacy code. Perhaps you are about to make some changes, and you'd like to be sure you don't break something else.

In your Test Setup, you find that first you need to set this, and you need to call that, and you need to make sure this data is set, and so on.

There's a number of problems here, but the one that I'm looking at in particular is that as you continue to try to get your tests to run, you find more and more prerequisites.

Suddenly your Test Setup is starting to get a little out of hand.

This comes down to code quality.

What is good quality code? It's fairly complex to define. As you try to add a "second client" to a given class, you find out if it's easy to have someone else use the code or not. In this case our second client is the Unit Tests.

Fair enough, if the code is doing something complex, there may be a lot of setup, but there are two problems here.

• It's not clear what setup is required.
• Perhaps the code should not be doing something so complex.

Of course TDD gets around this by writing the tests first, and many of the things that we consider "good quality" come from the constraints that Unit Testing forces on you.

In this same way, unit testing make code reviews more practical. Now you have a Clearer Metric for good code. If the code can't be tested, it's a good hint that the code is not Good Code.

Before Structured Unit Tests, you had the pantomime code reviews -

• "that functions too long", 
• "oh no it's not", 
• "oh yes it is" 

Now it's simpler

• "that functions too long", 
• "oh no it's not", 
• "How come it's got no unit tests"
• "it's doing too many thing to test"
• "so it's to long then"
• "yes, I guess so"

A lot of the Code Quality which people used to call subjective, now has a practical metric. If it's hard to write unit tests for, then the code's not good code.

Branches and Code Quality

A while back I posted about not reformatting code and the problems you incur when merging branches. After some thinking, reading and discussion, I'd like to partially recant that advice.

I still think that moving brackets around in the code is pretty much a waste of time compared to things you could tidy up which make code easier to understand.

But more and more I think that the cost of a merge made a little more difficult is repaid many times by improving the code quality.

Martin Fowler has quite a lot to say about branches.

But in general we read code a lot more often than we write it, so I'm more and more prepared to amortize the cost of fixing poor and mediocre code for the benefit of less confusion, less bugs, more tests.

The Partial Class anti-pattern

In c# you can have a partial class.

This has a very specific function. It allows you to separate "Widget Generated Code" from the rest of your code. Then if you run the widget again, it won't overwrite all the additional code you have added. Think Windows Forms.

Of course when a class gets too large, you could* break up the class into multiple files, and use partial classes.

But this is very much brushing the problem under the rug.

Now you have made things worse.

If you have succeeded in breaking up the class into two or more partial classes which do not access private variables or private functions from the remainder of the partial class, then make it a brand new stand alone class.

If not, you now have a mini program within a large program, where you essentially have Global variables and functions  (albeit marked as private) which can be changed by code from another file. You can no longer see what is going on.

OK, in fairness you can use Resharper or some such tool to "find usages", but really you have just acknowledged the class was too big. Break it up into separate classes.


This 

• makes it more testable.
• reduces the scope of private and protected members. 
• may well separate out dependencies.
• allows you to have higher level code in the primary class and hides the details of "the other stuff".

*if you do this, allow me to suggest that you don't go boasting about it to all your friends.