Overlooking a once-everyday tool . . .

What Ever Happened to Source Code Listings?

©Conrad Weisert, Information Disciplines, Inc.,
10 March 2017


The February issue of ACM Communications features advice by "Kode Vicious", the pen name1 of a regular contributor on topics related to software engineering and programming practice. The current article under the headline "The Unholy Trinity of Software Development" is mostly about program documentation in general and source-code listings in particular.

While KV's advice is generally sound, the experienced programmer reader is struck by one puzzling omission: In the whole article there is no mention of actually printing a source code listing! KV discusses the capacity of traidtional display monitors (~25 lines) versus that of newer high-resolution monitors (~200 lines), noting that the former is clearly inadequate for viewing program source code.

Why bother to print?

Younger programmers may wonder why we should ever need to print a source program listing on paper when we can easly view it on a screen. Of course, that's a matter of personal taste, but let me offer the following arguments:

I would add one more very important consideration: The page size (about 55 lines of 11-point courier) on standard office stationery is well suited to the amount of code one can (or should) view at one time. Furthermore, it enourages appropriate use of white space and page breaks to clarify structure.

Finally, experience shows that a programmer can often spot a problem faster when looking at neatly printed paper on a desk than when staring at a crowded eye-level screen. Screen displays, of course, offer color, but color plays little role in reading source code, except perhaps to spot an unbalanced quote mark. Besides, we still have the colorful screen display after we've printed the source code on paper.

What ever happened to listing pseudo-ops?

I'm often irrirated when watching a presentation or even reading a book by seeing the first line or two of a program module at the bottom of a page. Old-fashioned assemblers and some higher-level language compilers supported an EJECT command, so the programmer could start a new item (e.g. a major subroutine or just a break in the logic) at the top of a page.

We also could use:
SPACE n (insert n blank lines)
TITLE text(Use text as a heading on subsequent pages.)
UNLIST(Suppress printing of subsequent lines, often standard library code.)
LIST(Cancel earlier UNLIST; i.e. resume printing.)

Whenever I've wondered why today's compilers don't support such listing controls, I've been advised (sometimes impatiently) that modern (i.e. younger) programmers equipped with large display screens no longer need to print their source code on paper. (Maybe more of them would if they had those controls. Maybe they'd make fewer costly minor mistakes, and maybe their programs would be easier for others to read.)

Related information

Too-long lines impair code readability.
Setting result to True or False.

1—Assumed to be George V. Nevillde-Neil

Return to IDI home page
Methodology information

Last modified March 12, 2017