Bad Code

August 28, 2002

Michael.Barr-August 28, 2002

Bad Code

Bad programmers seem to exist in every organization. The decisions they make and the code they write create more problems, hassles, and bugs than any interviewer can imagine.

Enough with the bad code already! While I've been discussing the subject of which language to use for embedded programming and how best to ensure a quality result the past few months, millions of lines of "bad code" have been newly written.

You've seen the kind of code I mean: modules and procedures carelessly divided (broken up as if to meet some arbitrary length limit, for example, rather than by purpose); variables randomly named, mostly global, a large percentage no longer in use; compiler warnings flagging a myriad of suspicious pointer and type conversions unheeded; comments-what few there are-mostly outdated; other comments full of code that once did or meant something, now doesn't (or does it?).

Bad programmers can write bad code in any language. I've encountered bad assembly code, bad C code, and bad C++ code. I'm sure those who program regularly in Ada, Java, and every other language have uncovered bad code in those languages as well. It's time bad programmers and their code were dragged into the light.

To achieve the best long-term results, it is often necessary to have the courage to discard bad code and rewrite it. If an organization can accept that the existing code was never worth the money spent to develop it in the first place, they can move on and look forward to a brighter future. Ultimately, the costs (including the rewrite) are often much lower.

I've replaced bad assembly code with new C code that was smaller, more efficient, and easier to maintain. (It was also developed more quickly and cheaply than the bad code and had far fewer bugs at integration.) I've similarly replaced bug-ridden C code with new C++ code that required about half the code and data memory-and was just as efficient.

I'm not trying to suggest that C is better than assembly, that C++ is better than C, or even that the original authors in these examples chose the wrong languages. (I've also rewritten bad code in the same language as the original.) I'm just trying to make the point that assembly doesn't always result in the most compact code; there's skill involved in achieving that result. And C++ code can be just as compact and efficient as C code-if you know what you're doing.

That, of course, is the important part. The programmer must know what he is doing. Too often that isn't the case. However they manage to get themselves hired, bad programmers seem to exist in every organization. The decisions they make and the code they write create more problems, hassles, and bugs than any interviewer can imagine. The costs are unbearable, particularly in real-time/embedded devices.

Well? Don't just stand there. Do something. If it's your own code that needs the fixing: read a book like Code Complete (Microsoft Press, 1993) and start learning how to write well-structured easy-to-read code, get a copy of lint, and obey the Ten Commandments for C Programmers (www.lysator.liu.se/c/ten-commandments.html). The version control system you aren't using should help you feel comfortable deleting no-longer needed code rather than commenting it out. If the fault lies elsewhere, tell someone who can do something about it before any more damage is done.

Return to the September 2002 Table of Contents

Loading comments...

Parts Search Datasheets.com

KNOWLEDGE CENTER