Code.Implant

An engineer wrote some code today that at first glance confused me. I read code like I read the English language, which is to say I read patterns of code and recognize algorithms to piece together program flow, and in this particular case I didn’t recognize the pattern.

Anyway, the code looked a little something like this and resided in a pretty large function (names have been changed and some code simplified to protect the innocent):

Obj *myObj;
objListIter = GetObjListIterator();

for (int idx = 0; idx <= objIdx; idx++)
     myObj = objListIter.getNext();

myObj->DoStuff();

It’s clever. Simple. Probably not the way I’d do it. In fact, it made me do a double-take to where I had to make sure I understood what the for loop was trying to do.

But that’s kind of the problem.

The loop is performing a common task (get an index in a list), but it’s doing it in a unique manner. Such a unique manner that even the author had to verify himself that the code worked properly. When I first saw the code it did not, but it wasn’t an immediately obvious bug because the algorithm was too unique in the first place.

And that’s a problem. It wastes time.

I know programmers who like to be clever. They like to show that they can solve problems in unique ways. They forget that there is a human aspect to software, that other programmers have to read their code and possibly modify it one day.

I also know programmers who like to be practical. They like to show that they can create working, lasting code by being straightforward in their code and working hard to ensure design integrity throughout the software. They remember that there is a human aspect to software, that other programmers have to read their code and possibly modify it one day.

Which type of programmer would you rather work with?

Filed under: Design