Why The Code Curmudgeon? Well, I’ve been coding for decades now. I’ve forgotten more languages than most people know, and one thing I still believe is (as my friend Bill once said to me): “All computer languages suck.” But as bad as these computer languages are, the people who code them are worse! (Of course I mean the way they code, not that they are bad people, because in most cases, they are not. )
Here’s the Rogues Gallery of languages that have been implanted into my brain at one time or another, in rough chronological order:
- Assembler for the CDC 8090
- Assembler for IBM 360/370/XA
- MLINK Script
- Visual Basic
Two glaring omissions: COBOL–OK, I may have coded a program or two for a course in that ridiculous language, but I consciously made an effort to avoid it. It just seemed like way too much typing for my taste. And then there’s Java–something I might have really have gotten into if I’d not been drawn in by the Siren Song of C# and .NET.
But this is not about slandering any particular language, as much as I might like to complain about the hideous syntax conventions that so many languages have inherited from C, or why I’ll never be able to remember all of the special variables in Perl, or how a man can simultaneously love and hate the C++ STL.
No, this blog is really a screed against bad coding in any language. You can write good, clean, readable code in the worst of languages, or you can write sloppy, dense, indecipherable code in the best of them. Ultimately it’s not about the tool, it’s about the craftsman. I’ve worked for many companies, in many industries, read code from many programmers, and I’ve come to the conclusion that most professional programmers are fair to poor coders. Why are they so inept as a rule? Lack of training, lack of caring, lack of time, lack of effort–who knows? All of the above. (Most of my work has been in the USA with a mix of American and non-American programmers, but mostly the former. I cannot say if things are any better outside the US. My guess is probably not.)
When I was in grad school, the bible of Computer Science was Knuth’s The Art of Computer Programming, a planned seven-volume set of which only three were produced. No matter that I probably only digested a tenth of the material, or that his choice of expressing algorithms in his artificial assembly language, MIX, may not have been his best idea, or that he never completed the work. What was inspiring about it then, and still is today, is the idea that programming was an art, albeit with quite a healthy dollop of science. I think it’s easy to convince people that programming is scientific (if for no other reason than we have all these great buzzwords and acronyms to confuse outsiders–and ourselves–with), but no one really seems to think there is anything artistic about writing a piece of code. Too often programmers are driven to get code out the door that is “good enough,” and all the art, and a good chunk of science, gets dumped overboard.
My contention is that coding is an art and a science. You need both. Just like a great architect needs an eye for what makes a building attractive and the skill to keep it from falling down, a great programmer needs to produce a program that does what it’s supposed to do without being a morass of spaghetti code that cannot be understood two weeks after it’s written by anyone, including the author.
My criteria for a great program or application are, in order of importance:
- Correctness: It does what it is supposed to do–it works, at least most of the time. (And when it fails, it doesn’t leave the environment it runs in a smoking ruin.)
- Performance: It does this without consuming inordinate amounts of resources: memory, CPU, disk I/O, network I/O, etc.
- Usability: The user of the program can interact with it naturally and without confusion, if there is a human user. For a non-human user (e.g. another program using an API), there are similar, if less anthropomorphic requirements.
- Extensibility: The program can be changed to add new functions, or fixed without breaking old functionality, in a reasonable amount of time.
- Readability: The program can be understood by another programmer with similar technical background within a reasonable amount of time, given the size and complexity of the code.
- Supportability: The program documents the significant steps in its mission and can provide detailed information as needed to aid support technicians investigating reported failures or incorrect behavior. It also includes a set of analysis tools to assist in these investigations.
Now these are just off the top of my head, and I’d be surprised if someone else had not already itemized these and perhaps other criteria before. My intent is not to claim these as some kind of commandments, just to provide a framework for my subsequent posts. I suppose the order of importance among the items is debatable, but that’s not a fight I want to waste time on. I suppose one could add more items as well, although I suspect I could rhetorically shoehorn them into one of the six above without too much effort. But I’m not so concerned whether the list is complete.
I want to discuss coding from a very micro-level–from the level of the individual lines on the screen that you see when you open up a code file. I want to provide concrete examples of what to do and what not to do with a program so you can meet one or more of the goals above. I’m going to talk about seemingly inconsequential things some times, particularly when it comes to improving readability. Like a house made of bricks, a program is built by the keystroke, by the keyword, by the variable, and if you don’t line up the bricks and mortar, the house will look rather shabby, it will be drafty, and it might even fall down.
Despite my intent to be language agnostic, I will primarily provide examples in C#. It’s my current language of choice (well, actually my employer’s language of choice ), but I think that’s incidental. One of my conceits is that C, C++, Java, C#, Perl are all so closely related that it shouldn’t matter.
That’s the idea, anyway, as of this inaugural post. Who knows how this will pan out, but I guess the motto of this blog will be:
All computer languages suck, so it’s up to you, the programmer, to make sure that your code does not.