The proliferation of bad code

For most people, programming is a skill acquired through books and tutorials. I believe that few people actually learn formally in classes, and even then its through books. Most of these sources include the basic how-to snippets of code to use this or that function, leaving out any form of error handling. Is anyone surprised then that most code produced doesn’t meet the needed quality and is full of bugs? No one can write bug free code, but I’m surprised by the horrendous quality that comes out, where all that matters is that the code works by hacking it, rather than write good code that can whistand the test of time., I am guilty of this at times as most people are. The issue seems to me to be that error and exception handling, as well as general checking, is not covered or addressed in most material. if it is, it is usually at the end or as a footnote. Although this tends to produce less lines of code that a novice can see and understand, it misses the critical error handling that is so much needed . The student is then left to fend for their own and try to come up with ways to make their code more robust. Usually, they won’t unless it breaks down (and by then it’s too late).

I’m of the persuasion that you have to hit the iron while its hot. Most people tend to keep the conventions and customs they learned at the beginning of studying a subject, and these are usually hard to break. Error handling seems to me to be at times more important than than an actual working code. Why you might ask? You write code once but run it a thousand times. The code will likely run fine when you write it at first. However, it will invariably break down during runtime because of this or that. The only way to handle it properly and understand the issue immediately is to handle errors the proper way.

One thought on “The proliferation of bad code

  1. I am a real “old school” programmer, I learned my trade on an IBM360 programming in PL/1 back in the 1970s. Microcontroller programming has a lot in common with the techniques we used then . Memory was at a premium as was computer time so we spent a great deal of effort in design and and “head testing” code before we ever let it near the compiler – one compilation a day was the norm. So you really had to understand the problem and the technology before trying to solve it. For example I once managed to reduce the run time of a program from 8 hours to a little under one hour by moving assignment statements which only needed to be done at the start of the program out of the “loop” which actually processed the file.

    One of the things that is really critical is to understand what can go wrong and prevent it from happening. We used to call this “defensive programming”. Unfortunately the market for programming tools seems to focus more on productivity and less on quality.

    Anyway, thanks for the Blog…interesting stuff

    Steve

Leave a Reply

Your email address will not be published. Required fields are marked *