A frequently given piece of advice for writers is to avoid long sentences. It’s one of the pieces of advice that I have always completely disregarded, as being obviously wrong: the thing to avoid is not long sentences, but complicated sentences. A sentence that is long can still be quite simple, if it doesn’t require the reader to remember previous parts of the sentence in order to parse the rest. Instead, each part of the sentence just extends the thought made in the previous one, with appropriate punctuation that shows the relationship between the two; a sentence of that sort can go on for many lines without confusing anyone. What is confusing is when a sentence does something like requiring the reader to remember which verb was used back forty words previously, before the sentence went off on a tangent. And the cure for such sentences is never as simple as just bisecting them. Often one can rearrange them to bring together the separated pieces of an idea; but if that doesn’t work, one has to drop the idea and then explicitly take it up again when one later comes back to it. Or, more brutally, one can axe the tangential remark; not everything needs to be said – or if it does need to be said, maybe it can be said somewhere else.

So if you find yourself breaking sentences apart to follow a rule that sentences should be short, you’re doing it wrong; if they can be broken apart without much trouble, they also weren’t any trouble for the reader to understand in the first place. It’s when you read a sentence, get lost, and have to backtrack to grasp its meaning, that rewriting is indicated.

Of course the difficulty in this is that just after you’ve written a confusing sentence, the thought that gave rise to it is fresh in your mind, so you remember what you were driving at even if most readers wouldn’t have a clue. The cure can be to run it by someone else, to wait a day (or maybe a week) and then revisit the text, or, in the long run, to just develop a sense of when a sentence is getting too complicated.

There is one excuse for complicated sentences, which is when you’re dealing with an underlying idea that is itself complicated, and you’re writing for a very narrow audience of people whom you expect to actually understand that idea. This is a rare circumstance; most writing – even most technical writing – has to be palatable to people who will just nod their heads at it without really understanding it. But sometimes one is writing for friends; and then the excuse that the sentence is no more complicated than the underlying idea can be a reasonable one. Even then, it still would be better to explain the idea using simpler sentences; but that takes more effort.

There is a similar state of affairs with writing computer programs, where people often insist that functions should be short. While much bad code falls afoul of that rule, the rule doesn’t really get at the essence of the problem. It’s not the functions which one reacts to by saying “okay, this is getting long, let’s move the top of it to its own function” which are the problem; it is the functions which one reacts to by saying “oh, dear lord, what is this function doing?” – or, in one’s own just-written code, “whoa, this is getting a bit hairy; how can I break it up into simpler pieces?” And the pieces do have to be simpler, for the effort to make sense; otherwise the reader of the code is left contemplating not just a horrible mess, but a horrible mess that has metastasized.

The reason people make rules about length rather than complexity is that length is easy to define, while complexity isn’t. Indeed, complexity is to some extent a matter of personal taste and experience. If you’re used to some particular code pattern, you’ll consider it less complicated than will someone who is seeing it for the first time. This also makes the rule to avoid complexity a rule that is hard to teach: from a beginner’s point of view lots of things about programming are complicated, so avoiding complexity would mean avoiding learning how to program. Instead, beginners must be given a set of easy-to-apply rules that aim at that end, such as avoiding gotos. Such rules are never perfect; but since they have been handed down by high authority, programmers often advocate them with near-religious fervor. Not that really good programmers do that; they have long since realized that these are just rules of thumb, not iron laws, and that there are times when disregarding them makes sense. But avoiding long functions isn’t even a particularly good rule of thumb; avoiding gotos, for instance, is much more to the point (though even to it there are exceptions).

Update (Mar 2, 2018): It seems worth adding an example to this article. Consider the following sentence from the book Higher Performance Sailing, by Frank Bethwaite:

“We were not very confident of these drift and light air measurements, because during the month or two over which we were evaluating this rig we never did get light air conditions steady enough to be confident that the boat(s) that were running square or nearly so, and the downwind tacker that necessarily swept widely from side to side of the rhumb line, were sailing in the same wind.”

That’s a sentence that I had to reread to parse. It starts readably enough, but in the trailing clause one has quite a ways to search to get to the verb (“were sailing”). A fix would be to reorder the sentence to move it up:

“We were not very confident of these drift and light air measurements, because during the month or two over which we were evaluating this rig we never did get light air conditions steady enough to be confident that the boats were sailing in the same wind, since the downwind tacker necessarily swept widely from side to side of the rhumb line, while other boat(s) ran square or nearly so.”

The meaning may still not be clear to readers of this blog, who likely are unfamiliar with the jargon of sailing, but the sentence is at least easier to parse. By the way, the use of this example is not meant to disparage Bethwaite’s book, which is generally quite good as regards both content and readability; that sentence is just a rare exception. And at that, it’s nowhere near as bad as the sorts of sentences that Twain described in The Awful German Language:

“An average sentence, in a German newspaper, is a sublime and impressive curiosity; it occupies a quarter of a column; it contains all the ten parts of speech – not in regular order, but mixed; it is built mainly of compound words constructed by the writer on the spot, and not to be found in any dictionary – six or seven words compacted into one, without joint or seam – that is, without hyphens; it treats of fourteen or fifteen different subjects, each inclosed in a parenthesis of its own, with here and there extra parentheses which reinclose three or four of the minor parentheses, making pens within pens: finally, all the parentheses and reparentheses are massed together between a couple of king-parentheses, one of which is placed in the first line of the majestic sentence and the other in the middle of the last line of it – after which comes the VERB, and you find out for the first time what the man has been talking about […]”

These days, among English-speakers, efforts like what Twain described are only to be found in computer programs – which at least are indented to make the structure clearer.