
Google's Common Lisp style-guide - zaph0d
https://google-styleguide.googlecode.com/svn/trunk/lispguide.xml
======
zzygan
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.

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.

~~~
geofft
ITA continues to be heavy users of Common Lisp.

~~~
mck-
Do you know this for a fact? That'd be quite impressive if the Lispers
maintained strong against Google's policies.. I remember reading that they
ported over

~~~
7rurl
I have a friend who works for ITA/Google today, and he tells me they are still
using Lisp and their Lisp codebase is huge and complicated and not likely to
ever be ported to another language.

~~~
mck-
That's awesome -- so with them publishing this style guide, are they trying to
reach out to the Lisp community for recruitment purposes?

------
ScottBurson
A very useful document that I mostly agree with.

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.

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.

~~~
rayiner
Using AND and OR to return non-boolean values is one of the best, most useful
parts of Common Lisp.

------
dribnet
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.

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
_against_ using macros when writing code that other people will have to
maintain.

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.

~~~
x1024
No, Steve's rant was also about how Google is very much on the "Conservative"
end of the political spectrum. When a conservative company uses an - as per
steve's article - liberal language, you can't expect them to use it in a
liberal way. The story checks out.

~~~
calibraxis
I disagree. The Common Lisp community commonly has had the advice to be
sparing with macros. Dan Weinreb (of ITA and the Common Lisp standard)
mentioned this about ITA pre-Google. Paraphrasing from memory, "You can use
functions anytime. With macros you need justification. With reader macros, you
need a LOT of justification."

The conventional advice is not to go nuts with macros. In normal Common Lisp
code, you don't need to write many macros. And when you do, they're typically
with- macros.

Now, you can be a heavy _consumer_ of macros. That's something else. Like
using the LOOP macro all the time, for instance. The DEF... forms too. If
you're building a powerful new abstraction, like OOP or the metaobject
protocol, then it's great to have powers normally reserved for language
designers.

Also, see Rich Hickey's points:
(<http://news.ycombinator.com/item?id=4366661>)

------
JabavuAdams
I've often thought that stylistic (as opposed to semantic) formatting rules
should be enforced by pre/post commit scripts or nanny scripts.

This would be a huge pain with hard-to-parse languages like C++, but might
work a lot better for C / ObjC / CL / Java.

Just put your braces wherever they make you feel special, and let the
formatter sort it out.

Anyone do this?

~~~
agentultra
I do this in Python-land. There's a tool called 'pep8' named after the
community sanctioned style-guide of the same name. Before I push any changes I
have a script that runs my tests and the pep8 script. It's more of a backup-
measure in my case since I have my editor run pep8, lint, and my unit tests
constantly.

~~~
gecko
Indeed, and combining it with pyflakes makes for a great combo, ensuring that
code you commit _both_ looks generally correct, _and_ passes basic sanity
checks.

------
brudgers
_"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."_

This is how one endeavors for mediocrity within a creative pursuit. Crap gets
polished to a bronze sheen.

~~~
Aykroyd
That argument doesn't make sense. My outlet for creativity is the content of
my code not when new lines happen or how I indent. On the other hand, if
everything in the codebase is formatted uniformly it's a lot easier to scan
through and you don't end up with diffs filled with reformatting kruft as each
team member walks over the others' formatting style.

If you're feeling extra creative, you could always change your font, font
size, and syntax highlighting scheme. ;)

~~~
pmelendez
He could quote a better example, but I think the document goes deeper than
just formatting style.

From the article's excerpt "Principles":

* Don't be "clever" — do the simplest thing that could possibly work properly. * Be precise. * Be concise. * KISS — Keep It Simple, Stupid. * Use the smallest hammer for the job.

\---

They are indeed asking for uniformity against creativity. Which is not a bad
thing for corporations (IBM have very strong guidelines for years) but
definitely takes away that "hacker" aura that we gave to Google a few years
ago.

Any googler that can put this in context?

~~~
columbo
> They are indeed asking for uniformity against creativity

Well, I mean you could argue that this is clever, creative and beautiful (
[http://thedailywtf.com/Articles/Confessions-
rachetingDateObj...](http://thedailywtf.com/Articles/Confessions-
rachetingDateObject.aspx) ). To quote one of the comments "If I lean close
enough to the PC's speaker, I can hear the tiny clicks of all those wheels
spinning round - 'sbeautiful."

I don't think google is really arguing against creativity, rather saying
"don't be creative for creativity's sake".

I remember having to install Quartz Scheduler so it would hit a single servlet
every night at 1am. That's _ALL_ Quartz was used for. When I asked about using
cron the response was "well that wont scale"... this application had been
around for fifteen years and during that time there was only one batch
process... clever indeed!

~~~
pmelendez
There always would be anecdotal cases and interpretations. That's why I asked
an open question to a googler who could set the document into a context.

I also have cases of people doing a lot of ad-hoc code because it was easier
(small hammer to the job) and then resulted in a pain code to read that could
be prevented with a clever system. But I am agreed with you that the whole
thing is arguable and subjective

------
thebigshane
Related: ITA Software's Carl de Marcken discussing their use of Common Lisp
for Orbitz from 2001 with a 2002 update.

<http://paulgraham.com/carl.html>

Snippet:

    
    
      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.

~~~
ken
Yes, it looks like (besides the leftover "ITA" comment in the guide!) that
this is simply the ITA guidelines. From Carl's remarks, you can tell that ITA
is not a 'normal' Lisp program. Most Lisp programs do not preallocate ~5K of
data structures and fail-fast if they exceed that, for example.

Compare to the more conventional Norvig style guide (who is also of course at
Google today, coincidentally): <http://www.cs.umd.edu/~nau/cmsc421/norvig-
lisp-style.pdf> (PDF)

~~~
MichaelSalib
ITA actually has two large Lisp systems. One of them is the insanely optimized
fare search system (QPX) that does all the crazy things described in the link.
The other is the airline reservation system which is a much more
conventionally coded Lisp system.

------
Kototama
Is this due to the acquisition of ITA Software? I though Google was not in
favor of Common Lisp.

------
batgaijin
Congratulations, Robert Brown and François-René Rideau!

------
mck-
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:

(defun sum (numbers) (labels ((helper (todo ans) (if (null todo) ans (helper
(cdr todo) (+ ans (car todo)))))) (helper numbers 0)))

I hope that this is what the author meant with "iterative" approach, because
it is recursive by most standards.

~~~
gosub
Without TCO, doesn't your function overflow the stack, given that "numbers" is
long enough? By iterative I think they mean the use of "loop" or "iterate".

~~~
JabavuAdams
I thought that Common Lisp guaranteed Tail Call Optimization (TCO), but it
looks like it's actually up to the implementation:
<http://0branch.com/notes/tco-cl.html>

~~~
bitwize
Scheme guarantees it; CL only provides it as an option.

------
trhtrsh
Why is the content buried under a million collapsed arrows?

Should "grammar nazi" have a capitalized "N", or should the term be avoided in
a Style Guide?

~~~
aeontech
there is a large triangle button at top of the page with text "Toggle all
summaries" next to it.

~~~
mark_l_watson
+1 exactly right. I clipped this article to Evernote and had to toggle all
summaries visible first.

BTW, that is a great style guide, and mostly how I code in CL.

------
nnq
...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")

~~~
draven
You may find what you're looking for on either the ALU wiki
(<http://wiki.alu.org/>) or the CLiki (<http://cliki.net/>)

------
jasongaya
good one

