Long Subroutines

Subroutines should be short—50 lines is often quoted as an upper limit. This rule is widely known, widely accepted, and widely disregarded.

Long subroutines have many technical problems

They are hard to read and understand
They invite dependencies between unrelated sections of code
They are prone to sprawling control structures
They impede code reuse

The technical problems are real, but it has always seemed to me that they are somehow secondary: that there is something more fundamentally wrong with long subroutines. Something that gets to the very core of programming.

It finally occurred to me.

Long subroutines are run-on sentences.

Run-on Sentences

Children who write run-on sentences haven't yet learned that there is more to writing than transcribing their words. Good writing has grammar, sentences, paragraphs, chapters: it has structure.

Programmers who write long subroutines haven't yet learned that there is more to programming than transcribing their thoughts. Good software has syntax, statements, subroutines, modules: it has structure.

Programmers who write long subroutines aren't doing the fundamental work of programming: they aren't creating structure by which code can be partitioned and organized. They are just transcribing their thoughts, one after another.

Code vs. Prose

A 100 line paragraph would be solid block of single-spaced text, 2 pages long. Upon seeing a 100 line paragraph, most readers would intuitively feel that something was wrong, either with the ideas, or the writing, or the typesetting. Few would have the persistence or the patience to read it.

As it happens, all software has syntax, because the compilers enforce it. And programs above a certain size usually have some kind of module structure, perhaps because management requires it, or perhaps because they just become intractable otherwise.

But there doesn't seem to be anything that enforces structure at the subroutine level. Programmers write 100, 200, 500, even 1000 line subroutines, and as long as the code compiles and runs, no one objects. Few people ever see the code, and fewer still seem to think that it is a problem.

NOTES

seeing: This experience, nearly unknown in the print world, has become rather common on the internet, as existing ASCII documents are posted on the web without the necessary HTML markups.

Steven W. McDougall / resume / swmcd@theworld.com / 1999 Jun 27