DevExpress Newsletter 35: Message from the CTO

06 October 2010

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 Xamarin UI Controls

Deliver high-impact native mobile apps with our feature-rich Data Grid, Scheduler, Chart, TabView, Editors, and utility controls. Reserve your free copy today!
Felipe R Machado
Felipe R Machado

Do you know what really surprised me in this post? That link to Amazon for the set of lights and stands!!! Now that's a bargain price! Here in Brazil we can buy NOTHING of the sort for less than U$ 650!!! The rest of the article has no surprises, it is, as always, well thought, entertaining and correct.

6 October 2010
Steve Sharkey
Steve Sharkey

Whilst I totally agree with the parenthesis and in principle agree with variable names I do frequently use i, j, k as loop counters and quite deliberately so. To take a simple example, if I were inspecting a string one character at a time using a for loop if I use i as the index it's life is totally encapsulated in 4-5 lines of code so there's no scrolling up or down to find out what i is, and the important bit of the code is not masked by making the code unnecessarily verbose by multiple references to intCharacterPosition. So is it trying to "educate" us away from short variable names when coderush decides you meant something else as soon as you press space ;o)

7 October 2010
Jan Derk Stegeman
Jan Derk Stegeman

I just sent a feedback message about the poor sound quality of this video compared to the other ones. Now I understand why. Lower quality videos sure are fine when you are not able to use the usual video equipment, but maybe you should mention it shortly at the beginning of the video.

Good topic too.

Writing readable and thus maintainable code is #1 of my list of programmer rules. I always say: Source code should look like an English novel and your or my mother should be able to read it and understand it.

8 October 2010

Please login or register to post comments.