Google's Common Lisp style-guide

https://google-styleguide.googlecode.com/svn/trunk/lispguide.xml

by zaph0d • 14 years ago

178 57 14 years ago

google-styleguide.googlecode.com

zzygan• 14 years ago

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• 14 years ago

ITA continues to be heavy users of Common Lisp.

mck-4• 14 years ago

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

hollerith• 14 years ago

>This must have come out of the ITA Software acquisition

One of the authors, the one that goes by the name Faré, definitely came with the ITA acquisition.

batgaijin• 14 years ago

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

trhtrsh• 14 years ago

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• 14 years ago

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

mark_l_watson• 14 years ago

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

pohl• 14 years ago

About your second question, I like the following advice: "I would recommend lowercase, if you are not actually referring to the Nazi party, its members, or principles."

http://english.stackexchange.com/questions/73948/grammar-naz...

ScottBurson2• 14 years ago

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• 14 years ago

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

Kototama• 14 years ago

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

jasongaya• 14 years ago

good one

dribnet• 14 years ago

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• 14 years ago

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• 14 years ago

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)

epsil• 14 years ago

Link to Steve Yegge's post:

https://plus.google.com/u/0/110981030061712822816/posts/KaSK...

JabavuAdams3• 14 years ago

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

This is not arguing against macros, per se. The most powerful feature of macros is controlling how / when arguments are evaluated. So, if you don't use a macro when a function (i.e. standard arg evaluation) will do, you're not missing out on the power of macros.

pnathan• 14 years ago

Disagree, this advice regarding macros is mainstream Common Lisp thought. It's certainly been repeated enough on #lisp.

And, ah, the google CL team is, AFAIK, the former ITA, which was one of the top known Lisp shops worldwide. They know their Lisp.

aidenn0• 14 years ago

Yegge is wrong about this. It is generally accepted in the Common Lisp community that you avoid macros whenever possible. Here's a quote from pg's "Beating the Averages"

"Macros are harder to write than ordinary Lisp functions, and it's considered to be bad style to use them when they're not necessary."

mck-4• 14 years ago

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• 14 years ago

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

JabavuAdams3• 14 years ago

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

ScottBurson2• 14 years ago

I think they consider that recursive.

However, all the major implementations (SBCL, Clozure CL, Franz Allegro, LispWorks, CMUCL, and I think even ECL) do tail-call elimination on local calls. (A local call is a call to a function whose definition is lexically visible, such as the calls to 'helper' in your example.) The document says that TCE depends on optimization settings, but for local calls, I'm not sure even that is true. Anyway, the practical upshot, in my experience, is that there's no reason not to write loops recursively using LABELS when that is the most elegant expression of the particular loop in question.

(There was once a major implementation that never did TCE -- Genera -- but even for die-hard Lisp Machine lovers like myself, it has long since been relegated to a historical curiosity.)

mck-4• 14 years ago

Thanks for that Scott, I've never heard of TCE -- learn something every day reading HN.

Just did a quick comparison (SBCL) between the above and the textbook version:

(defun sum (list) (if (null list) 0 (+ (car list) (sum (cdr list)))))

This version quickly dumped Heap Exhaustion. The LABELS version does not, and can handle summation over lists much faster as well.

What does this mean? TCE only applies applies to local calls, therefore we should never write a "raw" recursive function? (which is a tad more elegant, imo). I haven't delved into TCOs deep enough to understand, but I had hoped that a smart compiler would be able to optimize the latter?

nnq• 14 years ago

...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• 14 years ago

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

brudgers• 14 years ago

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

Kaali• 14 years ago

I would prefer that the creativity in software development does not come from where you put your parenthesis or spaces. The creativity is in the solutions.

mikeash• 14 years ago

The key words here are "by its style". There's still plenty of room for creativity in how you structure the code, how you approach solutions, etc., which is where the creativity belongs. Mediocrity is not overcome with creative spacing.

Aykroyd• 14 years ago

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. ;)

pmelendez3• 14 years ago

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?

JabavuAdams3• 14 years ago

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?

BCM43• 14 years ago

I do this with perl. I use emacs' cperl mode, but I have Ctrl+x t bound to perltidy-buffer, which formats everything for me. I've modified the rules slightly (people at my work like tabs instead of spaces) but I tend not to spend too much time worrying about stylistic formatting rules.

Of course, this does not apply to some areas of vertical white-space, which I still have to manage myself.

agentultra• 14 years ago

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• 14 years ago

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.

fusiongyro• 14 years ago

Go famously comes with gofmt for exactly this reason.

tomjen3• 14 years ago

We have a script to autofix these issues. Interestingly enough the only things I would give a shit about are those that can't be fixed manually (e.g missing comments).

tbirdz• 14 years ago

astyle works fine with c++

jrockway• 14 years ago

We do this at Google, though humans are responsible for actual enforcement -- you can check in code even if it has lint errors, but your code reviewer should tell you not to. (For things like build files, though, you can't check in code with lint errors. That just saves everyone time and frustration.)

thebigshane• 14 years ago

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• 14 years ago

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• 14 years ago

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.

Google's Common Lisp style-guide

Related Stories