Why Punctuation Matters In Code (And In Life)

One of our main arguments at Mind Your Language is that the correct use of language, including punctuation, is essential because it ensures you look professional and convey your meaning accurately. The revelation of a major security hole in Apple's iOS and Mac OS X software caused by a tiny coding error reminds us that accuracy with punctuation matters even more to developers, as the University of Western Australia's David Glance explains.

Brackets picture from Shutterstock

Many people are aware of the dangers of missed punctuation as is highlighted by the campaign "Use commas. Don't be a psycho.". This is graphically illustrated by the accompanying statement "I like cooking my family and pets". What the public may not be aware of are the extreme dangers of similar missing punctuation in computer code. Certainly, developers at Apple have been reminded of this with the revelation last week of a bug that makes the secure communication of all of Apple's devices fail and if exploited, all transactions and conversations visible to attackers.

Apple issued a fix for its mobile devices on Friday but is yet to fix the issue on its laptops. For the time being, Mac users can mitigate some of the risk by using Firefox or Chrome instead of Safari.

Although fairly disastrous for users, the bug has proved a major embarrassment for Apple, especially so when it became known that the bug was caused by an unintended slip of grammar by an Apple developer.

Computer code is written in various languages that follow rules of grammar in much the same way as any spoken language does. Like a spoken language, computer languages like "C" and "C++" and Apple's favourite "Objective-C", use braces "{" and "}" to mark the beginning and end of statements that should be treated together.

What happened with the bug that the Apple developer introduced is that the programmer didn't use any braces for a piece of code that looked something like:

[1] if (certificate check is not valid)
[2] goto fail;
[3] goto fail;
[4] if (next certificate check is not valid)
[5] goto fail;

The problem lies with the line of code [3], the extra "goto fail". It is a redundant line of code that was left in by error. The developer didn't notice it because he or she wasn't using braces -- a convention that is allowed in coding in C if there is only 1 single line after the if statement [1]. Because of the fact that there wasn't a brace, it looked like line [3] was part of the if statement but it wasn't and would stop the check on line [4] from ever being run.

What the code should have looked like is this:

[1] if (certificate check is not valid) {
[2] goto fail;
[3] }
[3] goto fail;
[4] if (next certificate check is not valid) {
[5] goto fail;
[6] }

Developers commonly use what is called a "walk-through" to detect these types of errors. Each developer sits down with at least one, but usually, two other developers and they explain their code giving the group a chance to review the code and check it is doing what it should be doing.

This didn't happen in this case and somewhat surprisingly, despite the code being publicly available, it hadn't been picked up by any open source developers either. Adam Langlay, a Google developer and the person who explained the source code bug, maintained that a bug of this type was unlikely to happen at Google -- but I'm personally not so sure. People are unreliable at spotting grammatical errors and this is why it is important to adopt practices that minimise the chances of those errors happening. It is possible to get the language compiler software (the software that converts the code into something the computer can run) to warn against these types of error, but by default it doesn't have this option switched on.

It is not known whether anyone has exploited this bug yet but it seems unlikely that, despite claims, it was introduced deliberately for that purpose. Again, there are many ways that hackers can exploit users and subvert security without resorting to this type of unknown bug. In the meantime however, I guess Apple should be telling its developers "Use braces. Don't be a psycho who puts all of our users at risk."

David Glance is Director of Innovation, Faculty of Arts, Director of Centre for Software Practice at University of Western Australia. He does not work for, consult to, own shares in or receive funding from any company or organisation that would benefit from this article, and has no relevant affiliations.

The ConversationThis article was originally published on The Conversation. Read the original article.

Lifehacker's Mind Your Language column offers bossy advice on improving your writing.


Comments

    Ugh. At uni I had to stitch together COBOL code from my group's deliverable, only to find that all the coding standards that I set up at the beginning were not followed. As a result, the code sucked - periods that end the module were in the wrong place (or none at all), no spaces in between modules so I could work out where it started or ended (or spaces inexplicably within the routine itself), indentation inconsistent (helpful for COBOL) nested IF statements that made you go crazy trying to understand all the outcomes, no comments to explain what the module did, old modules that were rewritten but never removed from the code, etc. I had to re-format the code so that I could trace it properly to make sure it actually worked. Learned the hard way - don't do the quality check at the end, do it every few weeks. Thankfully, I don't have to code in my career.

    Coding is a bit of an art form - you need to make it look clean so that people can follow it properly for future maintenance. Sometimes, you just have to be anal.

      I agree, I remember working in a group project and we had one guy whose code seems to work, but was completely unreadable to everyone including himself. He wasn't even sure how it was working. That's why I always properly comment, indent and structure my code. If for nothing else but to make it easy to read for me months/years down the track when I no longer remember what it was I was trying to do when I originally wrote it.

    The CSS of this site has so clearly munged the meaning of the second psuedo-code snippet to be close to unintelligible for anyone but a programmer... and we don't need such inane comments like:

    It is possible to get the language compiler software (the software that converts the code into something the computer can run) to warn against these types of error

    To any programmer, including whoever made the error, this line is simply a dumb error. Brackets would 99% likely not have helped to find it.. Simply because it shows that the programmer was probably rushing it and not paying attention. The actual error is incidental

    It's like saying "oh if your indenting was tabs not spaces, or your editor had properly indented by detecting you used a conditional with no curley braces (limited to one expression) then this could have been avoided." - in the end its coincidental to the actual problem. For all you know the coder could have ended up with curly braces like:

    [1] if (certificate check is not valid) {
    [2] goto fail;
    [3] }
    [4] goto fail;

    In the end of the day, it is extremeeeely common if not by now the industry standard, to do single expression conditionals without braces, as they serve no technical purpose (as there's nothing to group).

    When one expression is EXPECTED but multiple exist, this is universally a problem - and you probably aren't adhering to specification.

    Curly braces even in an ideal setting could only have prevented the error, not the actual problem (duplicate code/multiple expressions for a block specified to only have one) - which might seem ideal in this situation as a consumer, but is realistically irrelevant to anything to do with the development.

    TLDR; Just fix the problem. The "why" at this point is irrelevant, and your assertion overly simplistic.

    Which is why my coding standards include always using braces when expressing conditionals, and religiously observing correct indentation. The coder will always make a mistake from time to time, but the coding standard serves to give them the best chance to spot it.

    ... if it was hard to write, it should be hard to read ... :^)

Join the discussion!