embedded software boot camp

The Crap Code Conundrum

Friday, June 29th, 2012 by Nigel Jones

Listed below are three statements. Based on my nearly thirty years in the embedded space I can confidently state that: One I have never heard stated. Another I have rarely heard stated, and the third I hear a lot. Here they are in order:

  1. I write crap code.
  2. You know so-and-so. (S)he writes really good code.
  3. This code is complete crap.

If your experience comports with mine, then it leads to what I have coined the ‘crap code conundrum’. In short, crap code is everywhere – but no one admits to or realizes they are writing it! So how can this be? Well I see several possibilities:

  1. In fact a lot of so called crap code is labeled as such because the author did things differently to the way the reader would have done it. I think it’s important to recognize this before summarily dismissing some code. Notwithstanding this, I all too often find myself saying ‘this code is complete crap’ – because it is!
  2. This is related to point 1, and essentially comes down to different people have different ideas about what constitutes good code. For example I think wrapping code in complex macros is an invitation for disaster. Others see it as a perfectly good way of simplifying things. (I’m right :-))
  3. The code started out being pretty good and has degenerated over time because the author hasn’t been allowed the time to perform the necessary refactoring. I think this does explain a lot of the bad code I see.
  4. The folks that write crap code are completely oblivious to the fact they are doing it. Indeed it’s only the self aware / self critical types that would even bother to ask themselves the question ‘is my code any good?’ Indeed, the first step to improving ones code is to ask oneself the question – how can I improve my code?

My gut feel is that point 4 is most likely the main cause. Now if you are so self-absorbed that you wouldn’t even dream to ask yourself the question ‘do I write crap code?’, then I seriously doubt whether you’d be reading this article. However if you have crossed this hurdle, then how can you determine if the code you are writing is any good? Well I took a stab at this a while back with this article . However some of the commenters pointed out that it’s quite easy to write code that has good metrics – yet is still complete crap. So clearly the code metrics approach is part of the story – but not the entire story.

So a couple of weeks ago I found myself in a bar in San Francisco having a beer with Michael Barr and a very smart  guy Steve Loudon. The topic of crap code came up and I posed the question ‘how can you tell code is crap?’ After all I think that crap code is a bit like pornography – you know it when you see it. After a spirited debate, the most pithy statement we could come up with is this:

If it’s hard to maintain, it’s crap.

Clearly there are all sorts of exceptions and qualifications, but at the end of the day I think this statement pretty much says it all. Thus if you are wondering if you write crap code, just ask yourself the question – how hard is this code to maintain? If you don’t like the answer, then it’s time to make a change.

 

 

 

10 Responses to “The Crap Code Conundrum”

  1. Richard Hendricks says:

    Well, we don’t always have the luxury of spending the time to change code, especially if it isn’t ours and we’re paradropped into fix someone else’s issue.

    Even when it’s our own code, the code maintenance qualifier can be difficult to evaluate as you’re writing the code, since that is when you are most familiar with it.

    Step back a few minutes and ask yourself – What did I have to learn to write this code? What will someone, perhaps me, in the future like to know? Can I add some comments to explain why I am doing this bit of odd-looking code?

    If you spent hours/days figuring out why something is written the way it is, try and document it better for the next poor bastard (who may be yourself)

  2. Anonymous says:

    Yeah, I’d start with Richard above – if it’s hard to understand it’s crap, even if it’s great functionally. That’s my problem with the Linux kernel – it may be good, but the bar to understanding it, let alone changing it, is so high I find that situation to be crap. The people who work on it want it the way it is – no comments, no references, no explanation – if you can’t grasp what it does from the sparse code, you should leave.
    So code can be crap depending on the anticipated maintainer.
    I think code is crap if it is so delicately balanced that it will break if the wind changes direction. Often it gets written like that because there was no time to do it in a more robust manner. We have loads of code we use every day which is like this – the supre-clever guy who wrote it thought his objectve was to get a version working in the fastest possible time. He wrote it as if he expected to be the person who got called to fix the odd behaviour forever – then left.

    • Lundin says:

      Personally I strongly suspect that the Linux kernel code is indeed pure crap. I was very positive to Linux before I started to check on its kernel and other open similar Linux source projects. After diving deep into that code, I keep a safety distance of ten meters to every Linux computer.

      A good way to measure whether code is crap or not is to check the coding standard that was used when writing the code. If there is no coding standard, the code is almost certainly crap. If the coding standard consists of 10 pages regarding indention and brace placement, but does not mention fundamental things like program design, language features to avoid, undefined behavior etc, the code is almost certainly crap.

      Example of how a bad coding standard would look:
      http://www.kernel.org/doc/Documentation/CodingStyle

      Examples of how a good coding standard would look:
      http://www.misra-c.com/
      https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard

      • Nigel Jones says:

        Excellent points Lundin (as always). One observation though: the corollary doesn’t hold. Code written to an excellent coding standard can still be crap – but it’s harder to make it so!

        • Lundin says:

          With a standard like MISRA-C, it will be very hard to get away with the most blatantly wrong things. It will weed out all undefined behavior, place heavy restrictions on pre-processor macro goo, it will ban numerous common bugs and so on.

          MISRA-C is no style guide though (even though it enforces a style guide to be present), so you could of course still format your code in bizarre ways while the code remains MISRA-compliant.

      • oliver says:

        So how come you are even able to use any computing device at all? Or are you in the category ‘ignorance is bliss’? Bear with me here for a second.

        First off, how do you write (code) anything at all? You surely realize that you are doing your input via a keyboard, which most likly has crap sofware for their firmware. But lets just assume you wrote your own keyboard firmware or reviewed the keyboard fimware and belive it to be awesome. So lets ignore all the firmwares for a moment in your computer. I’m guessing its safe to assume you do embedded development for a hobby/living.

        So how is it that you compile your code? Some propriatery compiler? Are you sure that code is not pure crap? Nigel demonstrated clearly on this blog that some vendors example codes are horrible, and it was not limitted to one. So how can you for certain know, that the code quality is any different from the example. Nigel brought up some idea’s as to why, but those are just assumptions. Fact is, we don’t know how awesome or crappy the compiler/linker code from any propriatery vendor is (i’ll exclude gcc for now, as I’ll wrap up with that at the end).

        Then to get really silly, what OS do you use to write code? If Linux’s code quality is pure crap, how can you judge the code quality of OSX or Windows? In the last 25 years of using those systems, they never crashed or showed behaviour that would indicate the code quality to be good or bad? I got a feeling that it’s likly to be crap 🙂

        Then finally, with your strong aversion of keeping distance from _every_ linux computer, You cannot have an android based phone, right? Or what about your (wifi) router, how big do you think the chances are it not running Linux? Modem? Servers you connect to? This blog’s hosting server?

        I do not think it is possible to live life without bumping in or using Linux or Open Source Software. True, in 2012 this may be a slightly different, it was even so the case back then.

        The big difference however is, whether it be GCC, Linux or any other Open Source Software package, if it is so horribly bad, you can always either review it, give suggestions to developers and bless them with your wisdom, or send patches to actually fix it. Any approach you choose to do so, is still an enlightenment. Knowing something is bad, when where and why, must surely feel safer then not knowing anything at all? Knowledge is power afterall, and I much more prefer the evil I know, then the evil I don’t know. Head in sand and all that 😉

  3. KISSMonX says:

    学习了! 谢谢!

  4. Thanks, always enjoy reading your content.

Leave a Reply

You must be logged in to post a comment.