Google's Common Lisp style-guide

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

[hollerith]

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

[geofft]

ITA continues to be heavy users of Common Lisp.

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

[pnathan]

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.

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

[JabavuAdams]

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

[aidenn0]

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

[epsil]

Link to Steve Yegge's post:

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

[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?

[fusiongyro]

Go famously comes with gofmt for exactly this reason.

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

[BCM43]

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.

[jrockway]

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

[tomjen3]

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]

astyle works fine with c++

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

[Kaali]

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.

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

[mikeash]

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.

[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)

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

[ScottBurson]

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

[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?

[pohl]

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

[aeontech]

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

[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