"The Elements of Style", by Strunk & White. 92 pages.
For example, page 19: "Put statements in positive form."
Code is improved if booleans are put in positive form, such as replace:
if (!featureIsDisabled()) ...
with:
if (hasFeature()) ...
You might laugh, but I see the first form all the time. Sometimes I go on a refactoring mission to remove as many negations, nots, and bangs from the code as possible.
?? You mean this book-- "The Elements of Style is an American English writing style guide in numerous editions. The original was composed by William Strunk Jr. in 1918, and published by Harcourt in 1920..." [1]
Cool! 1920s book on English writing style inspiring your coding style.
My first reaction to the 'positive form' was to recall a conversation I had once with a retired programmer about flow control diagrams. They relayed how the normal form for these required, for example, the boolean nodes to exit True in one direction and False in another--but all similar nodes had to exit in the same direction.
I wondered if a paper-based design, once translated into code, might not include conditionals such as the example which seem awkward once the paper design is lost and forgotten.
Now I don't know which detail is more interesting--
How design methodology effects the comprehensibility of written code.
How I was inspired to apply natural language writing principles as programming best practices.
"Writing with Style, Conversations on the Art of Writing", by John Trimble is another great writing book (The second edition is 161 pages if you don't include the appendices).
The ability to communicate in writing is an important skill even for developers.
For example, page 19: "Put statements in positive form."
Code is improved if booleans are put in positive form, such as replace:
with: You might laugh, but I see the first form all the time. Sometimes I go on a refactoring mission to remove as many negations, nots, and bangs from the code as possible.