October 28, 2009 Leave a comment
October 20, 2009 Leave a comment
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 1st 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
October 13, 2009 Leave a comment
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 1st 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.
October 6, 2009 Leave a comment
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.