DevExpress Newsletter 35: Message from the CTO

A bit of a lightweight thought for this particular newsletter: I was concentrating more on the videoing of it more than anything else. Why? See below, but first the message:

Writing readable code

Recently, as part of my writing gig with PC Plus magazine in the UK, my editor asked me to write an article on the 10 mistakes every programmer makes. Number 1 in my list was the propensity for developers to write for the compiler, not for other programmers. The reason it came up first is that every programmer I know is guilty of this at some stage, even me.

The problem is people tend to forget that the verbose grammar and syntactical sugar required to make programming easier and more like writing text is tossed aside in the process of converting prose to machine code. A compiler or interpreter doesn't care if you use a single-letter identifier or a more human-readable one. The compiler doesn't care if you write optimized expressions with full knowledge of operator precedence, or whether you envelop sub-expressions with parentheses. It merely takes your human-readable code, parses it into abstract syntax trees, and then converts those trees into machine code (or possibly some kind of intermediate language). Your names are by then history.

So, why not use more readable or semantically-significant identifiers than just i, j, or x? These days, the extra time you would spend waiting for the compiler to look up longer identifiers is miniscule to the point of immeasurable. Similarly, using your knowledge of the ins-and-outs of the sub-sub-clauses of your preferred language's operator precedence rules in order to reduce the number of parentheses in some misguided effort to be more elegant will make no difference to compile time.

However, the much-reduced time it takes you or another programmer to read your source code when that code was expressly written to be self-explanatory, to be more easily understandable, to not require knowledge of arcane language rules, is quite remarkable.

Studies have shown that the proportion of some code's lifecycle spent being maintained is easily five times more than just being written initially. It makes sense to write your code for someone else to read and understand. Let your compiler sweat.

See the video here.

The quote that flashes up on the video at the end is from Robert L Glass’ excellent and thought-provoking book Facts and Fallacies of Software Engineering: “Maintenance typically consumes 40% to 80% of software costs. It is probably the most important life cycle phase of software.” In essence, the more we do to help the maintenance side of things at the outset when we write the code, the more we’ll help reduce the ridiculous amount of time we spend maintaining it. This preparatory work runs the gamut from writing clear, lucid code to using agile methods and continuous integration techniques. Do none of this and maintaining a program is quite simply a pain in the neck and will consume extra resources and time.

You may think that I seem to be poking at operator precedence a bit. The animation that Jeff added to the video at that point shows the complete operator precedence rules for C++. To expect anyone but C++ junkies to know it all and furthermore to take advantage of them to eliminate needless parentheses is completely counter-productive. Yes, the rules need to be formulated and written down for the compiler writers to follow, but everyone else? I tend to assume the multiplicative operators are of higher precedence than the additive ones, but after that, no way, José. Parentheses here I come.

[Aside. For various reasons, I was not able to be in Glendale for the recording of this message. I had to do it at home instead. I bought a Flip UltraHD video camera, a 7’ x 5’ green screen that folds up into a little bag, and a set of lights and stands. Jeff, our videographer here at DevExpress, and I then spent some time fiddling with the look-and-feel (I’d record something, upload it to Dropbox, then he’d download it and make suggestions to improve the end-result) to get an acceptable video. My first set of attempts was in our living room, but it has high ceilings and a wood floor so the sounds was very echo-ey. I then moved to our garage to try it there — it’s full of bits and pieces at the moment, no cars — and we worked out the set up that produced the best audio/video. Of course, the morning I recorded it I had to stop every now and then because someone would drive by.]

Free DevExpress Products - Get Your Copy Today