Benefit for unit tests

From today on I’m absolutely convinced that unit tests are great.

The last three days I refactored my current project a lot – in fact I added 10 classes, deleted 6 and changed 25. If I would have done that in the past without unit tests, I a) wouldn’t have done that and b) if I really would have done that, it would have probably taken me 2 weeks to realize that my uncontrolled changes aren’t working and I wouldn’t get it to work in a reasonable amount of time.

But with my 250 unit tests, I checked every refactoring-step if my code still does what it has to do. And with that, I was absolutely sure about my changes. So, thank you, unit tests!

Clean Code

I just read the german edition of Clean Code from Robert C. Martin. The introduction made me love this book immediately by a simple drawing. There are two things I’ll take along from this book:

1) For each function f let f.LinesCount < 20

2) Comments are evil

These two rules need some clarifications of course. In fact, the demand to keep functions below 20 lines is a result of another rule: Don’t mess with abstraction-levels. If you see a function with more than 20 lines, this should be a good indication for a mix of different levels of abstraction.

The second rule points in the opposite direction of what I’ve learned at university: one tutor said to me that there should be more lines of comment than lines of code, so that another person could easily understand what you wanted to say. Today with C# and Java, this isn’t true anymore. The code itself became the comment. No more cyptic function-calls or Hungarian notation but intuitive named functions and variables telling what they’re doing.

Although I’m still feeling awkward without any function-header-comment, I slowly try to reduce unnecessary comments like this:

‘ iterate through all alarms
For Each a In m_colAlarms

And transform it into this

For Each alarm In _alarms

The difference is not big but the sum of all changes generates a nice picture.

So, the first dozen chapters are truly inspirational. After that, the book takes a look on bigger examples how to refactor whole classes. This is done step-by-step and after some steps, it’s getting boring. My advice: just read the first 12 chapters and start coding!