I love style guides

Style guides have a long and distinguished past. Classic examples include Strunk & White's The Elements of Style, and The Chicago Manual of Style (can't resist that chance to mention my Alma Mater...).

When programming languages started to become moderately sophisticated, style guides soon followed; Ben Schneiderman's The Elements of Fortran Style was one of the first (it's reached its 40th birthday!), followed 5 years later by Brian Kernighan's The Elements of Programming Style.

I wasn't ever a Fortran programmer (though I was once a PL/1 programmer), but I read both those books cover to cover, several times.

Anyway, I'm a junkie for style guides in general, and for programming language style guides in particular. Nowadays they are a dime a dozen, but I still perk up when I hear of a new one and I go check it out.

So I was intrigued to see, recently, that the engineering team at Twitter had shared their Scala programming guide: Effective Scala. I haven't had a chance to program in Scala, but it's a very interesting language and I got a better feel for the language by reading through the Twitter style guide.

While highly effective, Scala is also a large language, and our experiences have taught us to practice great care in its application. What are its pitfalls? Which features do we embrace, which do we eschew? When do we employ “purely functional style”, and when do we avoid it? In other words: what have we found to be an effective use of the language? This guide attempts to distill our experience into short essays, providing a set of best practices. Our use of Scala is mainly for creating high volume services that form distributed systems — and our advice is thus biased — but most of the advice herein should translate naturally to other domains.

I like the fact that the Twitter team recognize that programs are written to be read by human beings:

Scala provides many tools that enable succinct expression. Less typing is less reading, and less reading is often faster reading, and thus brevity enhances clarity. However brevity is a blunt tool that can also deliver the opposite effect: After correctness, think always of the reader.

You can never tell what will pop up when you read programming texts; there is always something new to learn, and it may be hiding around the next corner. In this case, I stumbled upon The Cake Pattern, which was a programming pattern I hadn't heard of before.

The neat thing is that we can here switch between different implementations of the services (if we had defined an interface trait and multiple implementations). But even more interestingly, we can create multiple “worlds” or “environments” by simply composing the traits in different combinations.

It's a nifty technique, though I haven't yet figured out why it's called "The Cake Pattern". I guess I'll go read the paper.

Thank you, Twitter engineering team, for sharing your style guide, it was most interesting!