Common Lisp Style Guide

Also worth mentioning is Peter Norvig&#x27;s and Kent Pitman&#x27;s style guide. It&#x27;s got a bunch of examples but I&#x27;ve found the presentation helpful when thinking about style in general for other languages, too: <a href="https:&#x2F;&#x2F;www.cs.umd.edu&#x2F;~nau&#x2F;cmsc421&#x2F;norvig-lisp-style.pdf" rel="nofollow">https:&#x2F;&#x2F;www.cs.umd.edu&#x2F;~nau&#x2F;cmsc421&#x2F;norvig-lisp-style.pdf</a><p>The code in Norvig&#x27;s book &quot;Paradigms of Artificial Intelligence Programming&quot; is enjoyable to read as well. As a pdf the book itself is freely available: <a href="https:&#x2F;&#x2F;github.com&#x2F;norvig&#x2F;paip-lisp" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;norvig&#x2F;paip-lisp</a><p>And then of course there&#x27;s the classic Costanza guide at <a href="http:&#x2F;&#x2F;www.p-cos.net&#x2F;lisp&#x2F;guide.html" rel="nofollow">http:&#x2F;&#x2F;www.p-cos.net&#x2F;lisp&#x2F;guide.html</a> (not so much about style per se) that contains an important remark, &quot;There cannot be &quot;the one definitive guide&quot; to Lisp. What I present here is what I would have liked to have seen in the first place. Other people probably prefer a different approach.&quot;<p>A quick glance at the broader open source ecosystem will show anyone that most projects don&#x27;t follow this particular style guide, or this guide is silent on certain things that are probably considered good form enough to put in a company guide, like using uninterned symbols for packages, or using qlot for version pinning your dependencies and having reproducible builds in your CI system, or using UIOP for anything to do with file paths, or... One needs to get comfortable loading a system and then using the usual cross-referencing features of an editor (emacs, vim, atom (<a href="https:&#x2F;&#x2F;atom.io&#x2F;packages&#x2F;slima" rel="nofollow">https:&#x2F;&#x2F;atom.io&#x2F;packages&#x2F;slima</a>), really anything that can talk to a swank server...) since reading code will be the surest way to understand it, especially when it might not be laid out as you expect.

Contrary to a sibling, I think that Common Lisp very much needs style guides. Maybe not one, but some for various use cases. The standard library feels like a sprawling jungle and the Rambo-style idiosyncratic programming syndrome in the ecosystem doesn&#x27;t help. Like how do you fill a hash table idiomatically, or manipulate strings. On the other hand, the merits of the language itself keep me going back to it.<p>In my projects I often find myself wishing for some actually comprehensive and written down guide to maintain consistency and elegance. It&#x27;s hard to do it entirely in your head. I mean, even a multitude of these would be fine if they&#x27;d be explicit and followed. Let&#x27;s build roads through this wilderness. One day I&#x27;ll get around to (also) doing it myself ;p<p>The OP is quite short, but the Google guide they cite and some ones linked by others here seem interesting.<p>One thing I&#x27;d like sorted is naming CLOS writers and accessors as opposed to readers. I feels that it should be somehow communicated what they are.

One thing which Common Lisp needs the least today is the style guide :)<p>I&#x27;d love to see more apps, innovations, success stories and use cases.

I find that the first two points (Use Libraries and Write Libraries) in the way they’re presented conflict with each other and they also go against my personal experience, at least when it comes to robust code.<p>First, using libraries is great but it always comes at a cost so that I’m always performing a cost-benefit analysis before I choose a third party library. The best case is that the library is well-written, well-documented and close to authoritative, meaning it attempts to maximally cover the problem domain (and not just solve small parts of the domain, typically those parts that scratch the itches of the developer). A lot of libraries out there are far from the best case. Most Common Lisp libraries out there are very far from best case.<p>Second, writing libraries or as the CL Style Guide puts it: “In short: write many small libraries (and I’ll add here the implied when solving a specific problem).” This sounds nice in theory but I find that it often falls apart in practice. Most developers that set out to solve a problem are focused on the problem and it’s hard to get them to decompose that problem into libraries that are best-case. Far more typically, if they do end up decomposing the problem into libraries, they will do so in haste and will only do the minimum. Or they may not yet possess sufficient understanding of the domain that would let them write a “best-case” library. This leads to a proliferation of libraries with similar functionality, with no clear “winner”. No clear “best-case” library for others to use.<p>Thus we see the conflict between the two statements. I would reword them as such:<p>+ Use third party libraries but perform a cost-benefit analysis before doing so.<p>+ Only write libraries (meant for others to reuse) if you are willing to put in the best-case effort. If you are writing such a library, then do attempt to minimize third party dependencies. It makes it a lot easier for others to do a cost-benefit analysis and also more probable that your library will end up used. Choose best-case libraries to depend on.<p>The things we’re trying to avoid are duplication of effort, expansion of the library space with similar libraries - no standouts - that end up confusing newcomers and dependency hell where it becomes expensive to do a cost-benefit analysis.

one thing I haven&#x27;t found a solution for is how to make Lisp&#x2F;Clojure play nice with version control and diffs<p>you take something like this<p><pre><code> (defpackage my-package (:use :cl) (:import-from :alexandria :with-gensyms :curry)) </code></pre> and you want to add an item to the list.. so you need to change the :curry)) line to be :curry and then add a new item. anyone have a workaround?<p>Of course if you had a lisp with no parans then you&#x27;d never have this problem to start with...<p><pre><code> defpackage my-package :use :cl :import-from :alexandria :with-gensyms :curry :new-thingy </code></pre> &quot;Indentation is two lines per form&quot;<p>Emacs seems to always do one space for Elisp and Clojure and two spaces for &#x27;let&#x27; and &#x27;if&#x27; forms. or did I screw something up in my init file?

It&#x27;s been a long time since I used common lisp, but I seem to remember that the convention was to use <i>if</i> in a conditional expression and <i>when</i> for something that conditionally produces a side effect?

Hrmn. I don&#x27;t think I&#x27;ve ever seen Lisp code where both branches of an IF are indented the same amount...

I am surprised that the style guide is not written in Lisp. It&#x27;s very un-lispy.