This is not my work. It is the work of James Devlin and was originally at http://www.codingthewheel.com/archives/programming-aphorisms-of-strunk-and-white. The site is no longer available, and I have lifted this copy from The Wayback Machine (https://web.archive.org/web/20150223232119/http://www.codingthewheel.com/archives/programming-aphorisms-of-strunk-and-white) because I think it’s worth being generally available and searchable. Hopefully most people consider this reasonable usage. I’ve also lost some formatting, which I plan to correct later.
Programming Aphorisms of Strunk and White
2008 October 13
It’s been the bane of English students and the bible of creative writing teachers since the second World War. It’s older than you are, meaner than you are, and presumably, built from sterner stuff than you are. This book has survived air raids and artillery shellings. Its simple lessons of thrift and economy have denuded the world of more bad writing, over the last 70 years, than the shutdown of Google Reader and Geocities combined. That is why The Elements of Style, by William Strunk and E.B. White, is a classic, and that’s why you’ll find a copy of this book (no thicker than the width of your finger) ensconced firmly in the “software” section of our bookshelf.
Of course, “Strunk and White”, as the book is usually called, has nothing to do with software (it was originally written in 1920) and everything to do with writing: grammar, composition, and style for users of the English language. But in its 100 pages this book has more to say about the craft of software than many books you’ll find in the “Software” section of your local bookstore.
2.12. Choose a suitable design and hold to it.
A basic structural design underlies every kind of writingprogramming. Writers Programmers will in part follow this design, in part deviate from it, according to their skills, their needs, and the unexpected events that accompany the act of composition. Writing Programming, to be effective, must follow closely the thoughts of the writer programmer, but not necessarily in the order in which those thoughts occur. This calls for a scheme of procedure….in most cases, planning must be a deliberate prelude to writing programming. The first principle of composition software development, therefore, is to foresee or determine the shape of what is to come and pursue that shape.
A casual search-and-replace for “writing” with “programming” consistently yields paragraphs that might have been plagiarized, whole cloth, from Code Complete. Paragraphs like this one, which cautions the would-be writer programmer to design appropriately for the scale and complexity of the thing being built.
5.3. Work from a suitable design.
Before beginning to compose develop something, gauge the nature and extent of the enterprise and work from a suitable design. Design informs even the simplest structure, whether of brick and steel or of prose. You raise a pup tent from one sort of vision, a cathedral from another. This does not mean that you must sit with a blueprint always in front of you, merely that you had best anticipate what you are getting into. To compose a laundry list, you can work directly from the pile of soiled garments, ticking them off one by one. But to write a biography, you will need at least a rough scheme; you cannot plunge in blindly and start ticking off after the fact about your subject, less you miss the forest for the trees and there be no end to your labors.
Or this, about the dangers of pet languages, non-standard libraries, young people, and drums. Chase it with a shot of Sailing to Byzantium for good measure.
5.21. Prefer the standard to the offbeat
Young writers Inexperienced programmers will be drawn at every turn toward eccentricities in language. They will hear the beat of new vocabularies abstractions, the exciting rhythms of special segments of their society industry, each speaking a language of its own. All of us come under the spell of these unsettling drums; the problem for beginners is to listen to them, learn the words, feel the vibrations, and not be carried away.
Sometimes the software interpretation rings even truer than the original meaning of the phrase:
2.17. Omit needless words code
Vigorous writing programming is concise. A paragraph function should contain no unnecessary sentences statements, a sentencestatement no unnecessary words expressions, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writerprogrammer make all paragraphs functions short, or avoid all detail and treat subjects only in outline, but that every word line of code tell.
2.19. Write Express coordinate ideas in similar form
This principle, that of parallel construction, requires that expressions similar in content and function be outwardly similar. The likeness of form enables the reader to recognize more readily the likeness of content and function.
Sometimes the attempt to replace writing with programming yields new insights.
5.9. Do not affect a breezy manner
The volume of writing source code is enormous, these days, and much of it has a sort of windiness about it, almost as though the author programmer were in a state of euphoria. “Spontaneous me,” sang Whitman, and, in his innocence, let loose the hordes of uninspired scribblers script kiddies who would one day confuse spontaneity with genius.
What does it mean to have a “breezy” style as a programmer? A plausible definition might be coding things in the order they occur to you, or to the degree they interest you. It’s a great recipe for spaghetti or, for the true code gourmand, mud. But without being “breezy” it’s also important to:
5.2. Write Program in a way that comes naturally
Program in a way that comes easily and naturally to you, using words and phrases APIs and statements that come readily to hand. But do not assume that because you have acted naturally your product is without flaw.
The act of writing code is a simultaneous conversation with two different audiences: the compiler/interpreter, and the other programmers on your team, including the future version of yourself. Good conversationalists — good coders — know how to speak to both audiences naturally and without affect. They know how to achieve clarity…
5.16. Be clear.
Clarity is not the prize in writing programming, nor is it always the principle mark of good style. There are occasions when obscurity serves a literary programmer yearning, if not a purpose, and there are writers programmers whose mien is more overcast than clear. But since writing programming is communication, clarity can only be a virtue.
…without being verbose:
5.11. Do not explain too much.
It is seldom advisable to tell all. Be sparing, for instance, in the use of </del>adverbs</del> code comments…Let the conversation code itself disclose the speaker’s manner or condition coder’s intention.
When we put on our “Bad Programmer” hats, on the other hand, we may not even be aware that the second audience, the human audience, exists. If we are aware it exists, we consider it secondary. In this state of temporary insanity, we might forget that, while part of our job is to talk to the compiler, the interpreter, and the toolchain, the bigger part of our job is to talk, through code, to our team members, maintainers, and stakeholders. Humans are the ultimate and primary audience for code. In that light, Strunk & White takes on new meaning and new relevance not just for coders, but for builders and creators of any stripe.