Jon Jagger
jon@jaggersoft.com

Sauce

At the ACCU 2002 conference Jim Coplien gave a keynote address. Jim asked whether people cared how their source code was formatted. Most people in the audience did. He said that how the code looked, its simple visual appearance, was really important and mentioned that one of his colleagues had done a study and had found a correlation between code formatting and bugs; better formatting correlated to fewer bugs.

This really caught my attention. There was absolutely no mention at all of the behaviour of the software. This was nothing to do with, for example, semantic warnings from lint; this was the simple physical appearance of the source. The way it looks to you and me. To people. Forget compilers. When Richard Gabriel (and Jim Coplien) tell you to study software they mean study source code. Not binary behaviour, but source code. For a while I puzzled over how Jim's colleague had managed to measure how well source code was formatted. I mean, formatting is notoriosly subjective right. Two programmers can argue for weeks about where to place braces and asterisks (star wars!).

Then I had an idea. A specific formatting style is pretty subjective, but consistency to a specific formatting style is not. For example, if you use a single space on either side of your binary operators then it makes sense to use a single space (not none or two) on either side of all your binary operators. The more I thought about it the more I realized just how many useful "features" of source code were non-behavioural, but detectable, and worth detecting. I immeadiately realized that to follow this line of attack I would need a parser that retained whitespace, comments, etc. I looked quite hard but failed to find such a beast. So I decided to write my own parser. I didn't have any prior experience of parsing so I prototyped some ideas for bits of the design for a week or so and then I just started. In the end what I designed and implemented was a parsing framework along with a set of lexical and syntactic grammars together with an ever increasing number of tools that use the framework.

Not long after I started Francis Glasborrow asked me to present at the ACCU 2003 Spring Conference. I'm increasingly wary of ungrounded software theory and more and more concerned with grounded software practice so I agreed to talk about my real-life experiences implementing a real-life software project. This is purely a part-time project that I tackle when I'm at home or on the road. This is all work in progress, usual disclaimer, etc. (lastly, to state the obvious, Sauce is a pun on Source.)

Browse the presentation.

Browse some sauce source!

 

{ JSL }
Jagger Software Ltd
Company # 4070126
VAT # 762 5213 42