I did not post this week – I haven’t done any new programming at all – I have been studying for my exam.  See you next week.

Speaking of Martin, I put together a list of highlights from his book Clean Code.

Following Kent’s 4 Rules of Design

1.       Run all of the tests

2.       Contain no duplication

3.       Express the intent of the programmer

4.       Minimize the number of classes and methods

(interestingly, #3 and #4 are often at odds.  As Martin says “ High class and method counts are sometimes the result of pointless dogmatism” (page 176)).

Writing code is an iterative process.  There are several catch-phrases you can use to reinforce that point:

1.       You need to write dirty code to get clean code

2.       Red light/green light/refactor

3.       Make it work, then make it right

4.       Refactor often, even working code

The reason it is iterative is because you will not get it right the 1^st time and you need to keep refactoring to move towards the single responsibility principle, etc… 

Readable code is a must – because the average developer spends 10 times as much time reading his/her own code when writing a new line.  I am sure that number is higher when it is someone else’s code (or their own code 1 year later).  Now I see why everyone wants to work on new projects – less code to read.

Code should be so readable that you don’t need comments.  It is not ok to write a good comment to explain bad code – fix the code!

Finally, in his Smells and Heuristics section, I found many of the things that I have done that kicked off a spidy-sense warning but until now, I have realized why:

·         Obsolete Comments

·         Commented Out Code

·         Too Many Arguments

·         Dead Function/Code

·         Prefer Polymorphism to If/Else or Switch/Case

·         Functions Should Do 1 Thing

·         Functions Should Descend Only 1 Level Of Abstraction

 

I am studying hard for my 70-568 exam at the end of the month so I have not dived deeper into development.  I did read Martin’s Clean Code over the last week and I found myself nodding in agreement more often than not.   I’ll never look at code comments the same way again.

 

I also started The Art of Unit Testing by Osherove.  I assumed that there were different levels of Unit Testing – good enough, good, and great.  However, Osherove doesn’t define it like that – he maintains that Unit Testing is a progression to Stubbing and Mocking.  If so, you need to refactor all of your code to include Interfaces and Dependency Injection and then use a Mocking Framework.  In short, there is no way to Unit Test an existing project that wasn’t set up for Testing in the 1^st place. 

 

I think this is where dogma meets progma (my word, use it at your peril)  – I know many projects that would benefit from basic testing (Unit, Regression, Integration or a combo/bastardization of all three) but to refactor the code to support IoC and Mocking is not viable.  I know that Unit Testing is still in its infancy so I wonder if additional patterns will develop to support testing that defies traditional definitions.

I am a big fan of using analogies to make a complex topic more accessible.  I was working though Microsoft .NET Framework Application Development Foundation by Tony Northrup when I came on a great analogy in his chapter on Code Access Security.  He used an example of a party that you are hosting (your method), a bouncer you have hired (.NET Framework Runtime),  4 guests you have invited (calling assemblies), and the invitation(s) you printed (the CAS permission of choice).  I had an a-ha moment with LinkedDemand and Demand.  I don’t use CAS on a day-to-day basis so I am not as familiar with the API – this will be a focus of my studies for my next exam (70-568 at the end of this month).

On another topic, I am reading The Pragmatic Programmer for light reading.  I think it is a great book.  I may not agree with some of their sections about coding, but their sections about personal development and programming ethos is spot on.