This must have come out of the ITA Software acquisition.... (Heading "Attention required" 'You must follow the ITA convention of using...')
They were a big common lisp user apparently.<p>Google is normally very specific on the languages allowed for internal projects. A product/company acquisition with large assets written in common lisp would necessitate this becoming the "Google Common lisp style guide" rather than what it was most likely originally the "ITA Software" common lisp style guide. Speculation of course, but looks likely.
A very useful document that I mostly agree with.<p>One area of difference is in the conditionals. I never use WHEN or UNLESS for value; only for effect. And, I never write NIL as one of the values returned by IF; I always condense the expression to AND or OR. That is, I freely use AND and OR to return non-boolean values; this is a practice some deprecate, and indeed, I'm surprised not to find it explicitly mentioned here.<p>I do like to write certain kinds of iteration as tail-recursions, but I always use local functions (LABELS) when doing that; there's no implementation I use regularly that doesn't do tail-call optimization on local calls.
This further reinforces how Yegge's recent "software political axis" rant was wildly inconsistent. His characterization of Clojure was "highly conservative" based in part on the best practices avoiding macros when possible, unlike "liberal" languages including Common Lisp.<p>Meanwhile in his own company's coding style for Common Lisp states very similar best practices regarding macros -- they should be used "sparingly and carefully", "You must never use a macro where a function will do.", etc. The whole macros section basically reads as a list of well thought out reasons <i>against</i> using macros when writing code that other people will have to maintain.<p>Yegge: "I trust that if you know anything about Lisp, your blood is basically boiling at this point." Really? Well then maybe the google CL team doesn't know lisp or otherwise are looking for novel ways to escalate their collective blood pressure.
I've often thought that stylistic (as opposed to semantic) formatting rules should be enforced by pre/post commit scripts or nanny scripts.<p>This would be a huge pain with hard-to-parse languages like C++, but might work a lot better for C / ObjC / CL / Java.<p>Just put your braces wherever they make you feel special, and let the formatter sort it out.<p>Anyone do this?
<i>"Everybody's code should look the same. Ideally, there should be no way to look at lines of code and recognize it as "Fred's code" by its style."</i><p>This is how one endeavors for mediocrity within a creative pursuit. Crap gets polished to a bronze sheen.
Related: ITA Software's Carl de Marcken discussing their use of Common Lisp for Orbitz from 2001 with a 2002 update.<p><a href="http://paulgraham.com/carl.html" rel="nofollow">http://paulgraham.com/carl.html</a><p>Snippet:<p><pre><code> ITA Software is slowly replacing the industry's hardware
and software with Common Lisp code running on Linux PCs,
that uses relatively involved algorithms that show off
our academic CS background.</code></pre>
I'm not sure I understand/agree the point about "iteration over recursion". One of my favorite aspects of Lisp is the recursive approach to writing functions. It's still possible to write recursive functions that don't rely on a specific compiler's optimization:<p>(defun sum (numbers)
(labels ((helper (todo ans)
(if (null todo)
ans
(helper (cdr todo) (+ ans (car todo))))))
(helper numbers 0)))<p>I hope that this is what the author meant with "iterative" approach, because it is recursive by most standards.
Why is the content buried under a million collapsed arrows?<p>Should "grammar nazi" have a capitalized "N", or should the term be avoided in a Style Guide?
...is there any place one can find a list of companies/projects using CL and specifically what they do with it? ..or of open source projects using CL? (or do people still treat it as "our secret sauce")