Homepage ->  Individual Weblogs -> Jeffrey Fredrick  -> SDBP: Clean Code by Robert Martin

September 12, 2006 - SDBP: Clean Code by Robert Martin

Listened to Uncle Bob give his Clean Code talk today and took some notes. Here are the bits I thought were worth sharing.

Bob started with the observation that the human form, the basic skeleton has been around a long time, and that for much of that time the basic technology wasn't very different from previous hominid. But then 50,000 years ago, something happened, there was this great explosion of tools... Bob never explictly linked this observation to his talk but I like to think that his implication was "listen to my talk or be left behind like the Neanderthals".

Bob asked for a show of hands: "Have you ever been significantly impeded by bad code?" Of course the kicker was the follow up question: "Why did you write it?" And indeed why do we keep writing it? What is it that makes us believe that to make a date we need to write crap. "I'll get done faster by making a mess" is somehow a deeply embedded belief, even though we know that this same mess is going to be causing us pain tomorrow.

Bob asked what can we do about bad code? The leading candidates are:

  1. The Grand Redesign in the Sky
  2. Incremental Improvement

As you can guess Bob was pretty skeptical about the first option. One of the problems is the Grand Redesign ends up as a long race between the new system and the old system since the old system keeps changing. Bob related his personal experience where this race lasted 10 years(!) before the "new" system caught up with the old system, but of course by then the new was pretty old and it was probably time for another redesign.

Bob gave a few simple rules for incremental improvement:

  1. Always check code in better than you checked it out
  2. Never let the sun set on bad code
  3. Test First! (provides the necessary flexibility)

In the Agitar dashboard there is data on code complexity, and when people see their numbers they often ask me what's a good target threshold. Not quite the same as complexity but still useful, Bob pegged desirable function size as being a dozen lines or fewer. The idea of "one screen worth" was fine when we all had 80x25 displayed but these days and with small fonts that idea is ripe for abuse.

I loved his observation that when you see lots of fields that's an indication that something has probably done wrong.

If you see a long if/else chain you should ask yourself if you should replace conditional w/polymorphism. Two reasons:

  1. open/closed violation: need to modify the code every time you want to extend
  2. DRY violation: you'll tend to repeat the if/else chain somewhere else

Also, in the code sample we were looking at there was lots of superficial symmetry, but the symmetry was really only functions w/similar names. Bob declared that as another suggestion that you need an object.

Bob made a great suggestion: "watch someone read your code, see what they have to do..." This idea of usability testing for code, the same way GUI people usability test an interface, seems a marvelous suggestion and I'm not sure why I've never heard the idea before.

Observation: One of the best ways to ruin a program is to make massive changes in the name of improvement. It's hard to get the program running again.

Chef parable: in a professional kitchen, when does the chef clean their tools? Answer: all the time! So that there is never a "washing" phase where they need to go a lean their knife, tongs, etc. Things are always kept clean so they can go as fast as possible.

Dinner parable: what's the fastest way to be done w/dinner? As soon as you're done eating just get up and walk away. But of course over time you'll find it hard to locate a clean fork or plate or serving platter, and cleaning up all the dried on crud is going to take more time. So the fastest way to spend time at dinner over all is to clean up immediately.

Observation: Nothing has a more profound and long-term degrading effect than bad code. Bad code rots and ferments. Professionals know that the only way to go fast is to go well.

Material for the talk was based on Bob's article Clean Code: Args.


Posted by Jeffrey Fredrick at September 12, 2006 12:35 PM


Trackback Pings

TrackBack URL for this entry:
http://www.developertesting.com/mt/mt-tb.cgi/229


Comments

Post a comment




Remember Me?