Received: by 10.224.223.14 with SMTP id ii14mr2846577qab.3.1350056787935; Fri, 12 Oct 2012 08:46:27 -0700 (PDT) Received: by 10.236.150.16 with SMTP id y16mr734159yhj.8.1350056787904; Fri, 12 Oct 2012 08:46:27 -0700 (PDT) Path: r17ni22505374qap.0!nntp.google.com!l8no46626888qao.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.lisp Date: Fri, 12 Oct 2012 08:46:27 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=178.14.0.87; posting-account=UVK8HgoAAADYdYbiG32r5K98C5HT6Ray NNTP-Posting-Host: 178.14.0.87 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <23c36afc-f490-48f7-a8c1-85bd013b4252@googlegroups.com> Subject: Re: Google Common Lisp Style Guide From: Antsan Injection-Date: Fri, 12 Oct 2012 15:46:27 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am Mittwoch, 10. Oktober 2012 21:21:26 UTC+2 schrieb Fran=C3=A7ois-Ren=C3= =A9 Rideau: > Dear Lispers, I've recently taken over the editing of a document now publ= ished as the Google Common Lisp Style Guide http://google-styleguide.google= code.com/svn/trunk/lispguide.xml Maybe some of you have feedback to improve= it. The hope is, if it gets good enough, it can be useful to newbies. =E2= =80=94=E2=99=AF=C6=92 =E2=80=A2 Fran=C3=A7ois-Ren=C3=A9 =C3=90VB Rideau =E2= =80=A2Reflection&Cybernethics=E2=80=A2 http://fare.tunes.org Common Lisp ma= kes it easy for you to grow your own language; however, it makes it difficu= lt for that language to be the same as anyone else's. Documentation: Document Everything I somewhere read that documentation strings very explicitely should *not* d= escribe how code works but rather what the code does. I very strongly agree= - how the code works shouldn't concern users and documentation strings are= for users. Naming: Denote intent, not content Personally I am more comfortable with knowing what kind of data can be proc= essed by a function. Parameter names should reflect that, I think. Naming: Omit library prefixes: Conflicts with your very own Language usage guidelines: Packages Naming: Predicate names the -p convention is very controversial and using ? instead is very popular= . The link provided doesn't explain why one shouldn't use ? or anything els= e instead. Data representation: NIL: empty-list, false and I Don't Know CL itself uses another convention for "I don't know": Provide multiple retu= rn values, the first being the found value (and a default one when none is = found) and a second value that is T if there was something found and NIL wh= en nothing was found. This seems more sensible to me then using some define= d symbol that might somehow end up being actually stored in the structure y= ou're searching in - even if it shouldn't. Everything regarding &allow-other-keys &allow-other-keys is useful where an &rest parameter is supposed to be a pl= ist and no keys are actually expected. Proper forms: Identity, Equality and Comparisons When checking for equality of places EQ is sensible I think. Proper forms: Iteration Controversial topic that doesn't need to be unified in style as all kinds o= f iteration constructs can be used in a way that is easily readable. When u= nsure what to use, look for the priority list as given above.