Long sentences

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).