The Zero Tolerance Approach to Programmer Punctuation

Lynne Truss’s Eats, Shoots & Leaves: The Zero Tolerance Approach to Punctuation is not only an amusing romp through a field of misplaced apostrophes, but a reminder of ubiquitous punctuation problems plaguing programmers.

Apostrophe Catastrophe

While Truss may balk at a London green grocer sign reading, “Tomato’s,” it is no worse a crime against civilized syntax than a program that spews SQL errors when an unwitting user enters names or addresses with apostrophes in them. Despite the fact that it is a well-known issue, it continues to rear its head, even in commercial software. The quote included in the data throws off the SQL string. Thinking this one had certainly made the rounds of all programmer toolboxes, I was surprised two weeks ago when a recently implemented vendor-written application began showing the tell-tale signs. Their workaround was to strip out all quotes from existing data and advise users not to use the offensive marks.

The lazy programmer advises the user to enter double apostrophes, which will solve the problem. However, another solution that doesn’t require user behavior modification is to use a replace function to insert an additional quotation mark where there was one, which makes SQL behave nicely.

Interestingly, a Google search for the terms SQL and Apostrophe yielded an article entitled: Apostrophe’s and Quotation Marks in SQL. The green grocer is in good company, it seems.

Tab Order Chaos

Programmers “punctuate” their applications in many ways to control flow and (theoretically) increase understanding. One is through screen layout and navigation. A sure sign of software slang is for the tab order to be illogical or to skip around the screen. Just yesterday I ran across an application that included a report criteria form. The cursor moved from Start Date to Employee and then to End Date.

Labeling Liability

Another programming punctuation peeve is for buttons to be labeled inconsistently within the same application. A popular labeling faux pas is liberal use of Back interspersed with Main Menu or Return or Exit.

Menu Mayhem

Grammatically and logically speaking, menus should follow parallel structure to increase accessibility and understanding, taking (and sticking with) the Verb-Noun or Noun-Verb form. However, even Microsoft products don’t adhere to this practice. Consider the standard Microsoft standard menu, beginning with File and ending with Help. Admittedly the word File could be a noun or verb, but coupled with the words Open, Close, or Save, it seems to follow a noun-verb form. Yet, joined with the word New, it assumes a Noun-Adjective structure. Next over, Edit, View, Insert, and Format appear to be used as verbs, but under Edit there are more verbs. Help is in a class all of its own and seems to make no attempt to follow any sort of pattern. Maybe a simple menu structure mirroring language is too much to expect, especially when complex systems are involved, but I expect it just wasn’t important to the developer who designed the GUI.

Does Punctuation Matter?

Lynne Truss explains that punctuation originated during the era of Greek dramas, as guidance to actors on how to speak their lines. It evolved in purpose to help readers resolve tricky sentence structures that could be interpreted more than one way. Perhaps I have stretched the language and punctuation analogy a little by applying it to the realm of software development. Since applications span multiple languages and cultures, applying English rules would be inappropriate. Yet, users can benefit from the sort of "punctuation" that doesn't draw attention to itself but manages expectations, drawing the eye (and mind) across the screen. When developers see applications with the problems I’ve described above—dealing with inconsistencies and blatant errors—we’re tempted to appoint ourselves as the Programming Punctuation Police.