Pet programming peeves . . .

Too-Long Lines Impair Code Readability
© Conrad Weisert, Information Disciplines, Inc., Chicago
22 July, 2008

NOTE: This document may be circulated or quoted from freely, as long as the copyright credit is included.


Several years ago we complained about trade journals and professional publications that squeezed program code examples into columns that were too narrow. The result was often code that was not only misleading to read but sometimes illegal. Another side of the same problem keeps popping up in code written by inexperienced programmers, especially students: lines of code too wide to be viewed in a normal screen window or on a standard1 piece of paper. The impact on program readability is severe.

That was never a problem in early programming languages. COBOL, for example, defined rigid margins for statements. So did Fortran and most assembly languages. If your statement didn't fit, you had to insert a continuation flag to divide it into two or more lines. Later languages (Algol, PL/I) did away with the continuation indicators, allowing free form code, but retained a fixed maximum line size, a concession to punched card input.

Then modern programming languages removed all those limitations. If you want to write a single Java or C# line that goes on for 250 positions, you can do so. If you print a listing of the code, that line either gets truncated or is wrapped to the left margin in conflict with hierarchical indentation. If you view it on the screen, you can also fall back on horizontal scrolling.

I've even attended a formal presentation where the lecturer was showing code examples on a projection screen. He kept having to scroll the display so that the audience could see the rightmost portion of a line or group of lines, by which time many of us had forgotten the leftmost portion. He was unapologetic, as if this were a perfectly normal way of showing source code.

Automating the wrapping?

Microsoft's Visual Studio editor offers a "Word Wrap" option that breaks lines too long to print or display. Unfortunately, it takes no notice of:

Here's an example of what Visual Studio does to an intrusive long comment:

   found = false;
   while (!found)       //  Search for a candidate
entry {getNextEntry(); if (someCondition) found = true; else ++nonMatchCount; } evaluateCandidate();

So the result is often very confusing to the reader. It's certainly possible to implement an "intelligent word wrap" capability, but why bother? The original programmer can and should simply break the lines at natural points while writing the code. The additional effort required is very close to zero.

Are overlong lines ever necessary?

Never in the C family of languages (C++, Java, C#).

An absent-minded slip

In most cases, the programmer hasn't deliberately chosen to write lines that exceed the width of a window or a page, but has just forgotten to pay attention to the margin. Old-timers may fondly recall typewriters that sounded a little bell when the typist was approaching the right margin. If today's code editors don't offer a bell, they do provide a display, usually below, of the current position. All the programmer has to do is glance at that counter and avoid going past a standard limit, usually 72 or 80.

I also make a final visual check looking for suspiciously long lines and bad alignments whenever:

1—Standard paper is either A4 (international) or (U.S.) 8½ inches wide. Extra-wide (14 inches) paper was commonly used for assembly languages where the source code and generated machine code were listed side-by-side.)

Return to IDI Home Page
Return to Technical articles

Last modified December 17, 2013