BUGS in Writing, Revised Edition: A Guide to Debugging Your Prose [Paperback]

If you don't mind all the cat pictures and personal references, it is a good book to browse for tips on improving your writing. Dupre states that her goal is to help the reader develop an "ear" for good writing. As you develop an ear, you will gain a sense of which of her rules to take to heart, and which to take with a grain of salt. It is *not* organized or indexed such that you can easily find a topic again. Do not expect to use it as a reference book when you have finished browsing.

Although the author cites the Manual of Style published by the University of Chicago Press, she failed to take to heart a number of its recommendations. In particular, her use of footnotes is excessive and often distracting. The overall design of the book appears very self-indulgent with its copious use of personal photographs unrelated to the text. The author is committed to "gender free" text to the point of altering the accepted names for famous computer science problems such as the Traveling Salesman Problem to suit her personal agenda and insists that others do likewise. She allows other petty issues to spoil her work. For example, she writes: "A dissertation is a document that you write as part of the fulfillment of requirements for a degree¡Ä A thesis is an assertion that you have presumably validated or proved ¡Ä" This is contrary to accepted practice at many and probably most academic institutions. While Martin Luther may have nailed his 95 thesis to a church door, some schools call even the paper presented for a doctorate a "thesis" while others reserve the term for a work presented for a master¡Çs degree. Current practice is to begin scholarly works with an "abstract" and not a "thesis".

Another of Dupres personal crusades is expressed in a foray against "split infinitives". She writes as if split infinitives are a recent abberation. In The Elements of Style, Strunk and White note that: "There is precedent from the fourteenth century down for interposing an adverb between to and the infinitive it governs." They also note that the "split infinitive" has a role when the author wishes to stress the adverb as in "To boldly go where no man has gone before." Strunk and White go on to note: "Some infinitives seem to improve on being split." Dupres¡Ç partisanship in the slit infinitive "wars" is much less disturbing than her one-sided account of the split infinitive.

Her diatribe against use of "data" as a singular in computer science is also excessive. Data is the plural of datum in Latin. The problem with treating data as a plural taking "are" in computer science is the distinction in English between enumerable and non-enumerable nouns. While there are uses of the word data where it is clearly plural, this is not the case in much of computer science literature where it is used in a non-enumerable sense. In English, the tradition is to treat non-enumerable nouns as singular. An odd recent development is pluralization of "email" as "emails" while "mail" continues to be treated as non- enumerable. Finally, data is often used as an adjective in computer science. English traditionally uses singular nouns for this purpose such as "horse barn" or "cow pasture" in preference to "horses barn" or "cattle pasture". Similarly, a famous English university is commonly called Oxford and not Oxenford. Insisting upon treating data as a plural would have much more serious consequences than portrayed by Dupres and other opponents of data as a non-enumerable. Under her system, we would properly write of "datum structures" rather than "data structures". In short, English majors should not meddle with semantics of individual words until they learn the field of discourse employing those words.

Although the author claims to have written a book for "computer people" she seems to be unaware of typesetting using LaTeX or the electronic style sheets provided by technical publishers. She also appears ignorant of coupling typesetting equations with output produced by either Maple or Mathematica. Although her book does contain a brief section on theorems and similar material, this section is too short and lacks sufficient detail to aid the reader. Despite her attention to typography, she does not make a clear recommendation on how to emphasize technical words in a work with lots of italicized text.

Some of the author's advice is well taken. She justly condemns use of passive voice in scientific writing. Her insistence on maintaining noun constancy is also well worth reading. Problems with noun consistency is exacerbated if you anticipate translation into Japanese where variation in nouns is less tolerated than it is in English. Unfortunately, even some of her good advice betrays a lack of understanding of computer science. While Dupre correctly argues for using monospace fonts for typesetting code, she appears ignorant of the reasons for preferring this convention. In one piece of advice she uses writing about stacks and queues as an example, but in her example labeled "good" she delivers confused prose which betrays ignorance of the subject. This spoils an otherwise good section.

In a world with many excellent books about writing, I can not recommend buying Dupre's book. If you are specifically interested in writing for computer science, then you should buy and read a copy of Writing for Computer Science by Justin Zobel. If you wish to write mathematics, you should buy and read a copy of How to Write Mathematics by Steenrod. The Art of Readable Writing by Rudolf Flesch continues to deliver excellent advice on writing in a much more compact package than Bugs in Writing. I also recommend Manual of Style by the University of Chicago Press, The Elements of Style by Strunk and White, and A Handlist of Rhetorical Terms by Lanham. As for BUGS in Writing, I can only speculate that Ms. Dupre made the error of editing her own book.