Those unsightly code sores - Embedded.com

Those unsightly code sores

Do you have those unsightly code sores? It’s not only the teenaged years that bring them on. All it takes is one developer with a bad code and suddenly everyone in the cubicle is hacking up nasty globs of code that’s sure to infect the entire repository. Often the culprit is a strain of MRSA (Madly Recursive unStructured Algorithms), which is especially common in teams working closely together in open spaces. MRSA has proven to be very resistant to even the most vigorous refactoring. To thwart its propagation it’s best to burn every instance found.

Here’s a few examples of code sores. I hope they’re not too contagious.
From the Linux kernel:

Don’t you just love those expressive variable names? There are no comments, of course, because those might give some vague hint as to the meaning of the function’s parameters.

From MQX:

The nice thing is that this misspelling will propagate into the Doxygen reports.

More from the Linux kernel:

No comments at all in or around the function, no description of what it does, nor is there the slightest hint what the arguments are.

I have seen the following general snippet too many times:

(No doubt it started as defining FIVE as 5 but successive attempts to fix the function led to this absurdity).

Apple’s SSL bug:

Had they followed MISRA rule 15.6 this threat, distributed to millions, could not have happened.

From a fellow who worked (briefly!) for me:

I dunno… is it right? You tell me! And what does “178” refer to?

Honesty is always the best policy:

The department of redundancy department:

One way to do a test:

An attempt to see if a number is odd:

Finally, this gem from the International Obfuscated C Coding Contest:

How is the health of your repository? Do you have favorite strains of code sores?

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges, and works as an expert witness on embedded issues. Contact him at . His website is .

13 thoughts on “Those unsightly code sores

  1. “I love the smell of troll-bait in the morning…nnThe second true/false handling code is legitimate, even if it looks odd.nnget_loc() might return a pointer etc and not a truth value. The code turns it into 0 or 1.nnWhat is even a more odd-looking

    Log in to Reply
  2. “I think a couple of those examples can be explained by one one of my observations, which is: Never hire a software developer who can't even describe the problem clearly, precise and without further ado in his mother language. Because his code won't be any

    Log in to Reply
  3. “For clarity of code, and also for compile time type checking, if get_loc() returns a pointer, then it could say:nnresult = (get_loc() != NULL) ? true : false;nnThe “? true : false” is still redundant though.nnOne of my pet peeves: so many #ifdef s

    Log in to Reply
  4. “For clarity of code, and also for compile time type checking, if get_loc() returns a pointer, then it could say:nnresult = (get_loc() != NULL) ? true : false;nnThe “? true : false” is still redundant though.nnOne of my pet peeves: so many #ifdef s

    Log in to Reply
  5. “The example was not nresult = (get_loc() != NULL) ? true : false; nnit wasnnresult = get_loc() ? true : false; nnThat would give the same result as nresult = (get_loc() != NULL);nornresult = !!get_loc();”

    Log in to Reply
  6. “It's enough to make you cry… :o)nnThe book Code Complete: A Practical Handbook of Software Construction, Second Edition by Steve McConnell is a great reference for this sort of thing. In my opinion most companies should make it a compulsory read befo

    Log in to Reply
  7. “I used to use a Louisville Slugger baseball bat to deal with this cruft! I was finally asked to not whack our engineers upside the head because they were idiots! I downsized to a nerf-bat instead… :-)n”

    Log in to Reply
  8. “I think the line:nnresult = get_loc() ? true : false; nnis absolutely appropriate for good code. It serves readability and explicitly shows the Boolean nature of the result while insulating the return type of the test function from the result variabl

    Log in to Reply
  9. “One idea that emerges from the SSL bug is running the code through an indenting tool before code reviews.nnThat would fix the indented goto.nnSome indenting tools can even MISRA-ise C code and add the braces.n”

    Log in to Reply
  10. “Yes, Code Complete is excellent. I have on two occasions, gone through the entire book with more junior engineers, one chapter a week. We sat down and discuss it and found examples in the production code to fix and refactor. Amazing improvements were made

    Log in to Reply
  11. “Using the MISRA 15.6 Rule with Allman style would allow a different species of bug:nif ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0);n{n goto fail;n}nnAfter writing/debugging several million lines of code (mainly other peopleu2019s

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.