Clojure indentation conventions
levand
about lisp indentation & newline conventions.
Some things are easy to pick up from posted examples and common
sense...newline + tab after the parameters vector when defining a
function, etc.
But I did some web searches on lisp & emacs conventions, and some
things aren't so clear. For example, this googled web page (http://
dept-info.labri.u-bordeaux.fr/~strandh/Teaching/MTP/Common/Strandh-
Tutorial/indentation.html) indicates that in the "if" special form,
each sub-expression should be aligned. Is this accomplished by tabs +
spaces until they align? What if the editor isn't using a fixed-width
font (or is it assumed that it always is?) Or is that the emacs editor
aligning things irrespective of what whitespace characters are really
there?
Which leads to the other immortal question - tab characters, or [n]
consecutive spaces? I'm fairly ambivalent myself and can go either
way, but is there a clear preferred way in the clojure community that
I would be better served by adhering to?
Does anyone know of a reference for, or would care to enumerate what
standard clojure indenting ought to be?
I'm particularly interested in this as I've been hacking about with a
clojure eclipse plugin for my own use and am considering adding auto-
indent features.
Meikel Brandmeyer
Am 03.12.2008 um 22:06 schrieb levand:
> I am coming to Clojure from the Java side, and am completely ignorant
> about lisp indentation & newline conventions.
Good. Then you aren't spoiled, yet. ;)
My advice: get a reasonable editor like emacs or vim and
the corresponding clojure modes. They will help you with
automatic indentation. Just go with that and you won't have
problems.
> Which leads to the other immortal question - tab characters, or [n]
> consecutive spaces? I'm fairly ambivalent myself and can go either
> way, but is there a clear preferred way in the clojure community that
> I would be better served by adhering to?
Never ever use tabs. Eg.
(some-function xxx
yyy)
is one way to format a multi-line function call. Mixing tabs and
spaces in front of the yyy just begs for ugly effects for people
with different tab settings. And since the function name in general
doesn't align well with tabs you need spaces anyway. So use only
spaces.
> Does anyone know of a reference for, or would care to enumerate what
> standard clojure indenting ought to be?
Personally, I like the vim way of indenting. But that's not a
reference of course.
> I'm particularly interested in this as I've been hacking about with a
> clojure eclipse plugin for my own use and am considering adding auto-
> indent features.
In that case, I'd suggest to pick a style you like from an other
editor or a particular library (eg. clojure.core itself) and try
to implement that.
This easily turns into religious flame wars. So my Disclaimer:
Nothing of the said (except maybe the tab thing) is any reference
and your mileage may vary!
Sincerely
Meikel
Mark Volkmann
I would like it if the team of Clojure committers would come up with
some basic guidelines for formatting code and maybe some advice that
goes beyond formatting. The kinds of guidelines I'd like to see are
the following:
Limit line lengths, perhaps to 80. Why 80? Because it works well with
printers and long lines of code are harder to quickly understand.
Limit the number of lines in a single function, perhaps with a goal of
15 being an upper limit. Why? Because it can be time consuming to
figure out what a long function is doing. If a function is longer than
that, odds are it is doing more than one fundamental thing and can be
broken into smaller, perhaps private, well-named functions that are
called from the original function. This can dramatically reduce the
need for comments.
Either put all the arguments to a function on a single line (if it
will fit in the line length limit) or put each argument on a separate
line. Anything else is harder to read.
--
R. Mark Volkmann
Object Computing, Inc.
mac
that has a lot to do with program factoring, not just aesthetics. But
80 characters for a line is a bit drastic.
Sure it prints well on paper but who prints code on paper anyway in
these times of laptops and projectors?
With only 80 characters on a line you have to make names very short.
Don't get me wrong, I'm all for short names but not at the expense of
clarity.
But as has been said, YMMV.
On the subject of indentation, I don't really know if I follow any set
pattern. I guess I just follow my gut. I use clojure-mode for emacs
and hit newline when I think it makes the code clearer and I let emacs
indent it for me.
Christian Vest Hansen
> I am partial to a guideline for number of lines in a function because
> that has a lot to do with program factoring, not just aesthetics. But
> 80 characters for a line is a bit drastic.
> Sure it prints well on paper but who prints code on paper anyway in
> these times of laptops and projectors?
> With only 80 characters on a line you have to make names very short.
> Don't get me wrong, I'm all for short names but not at the expense of
> clarity.
> But as has been said, YMMV.
I think the 80 character limit depends a lot on peoples style and work habits.
When I'm not writing Java, I tend to have my editor on one side of the
screen, and a couple of console windows on the other side. An 80
character limit makes sense in this scenario because it allows me to
copy and paste code from one side of the screen to the other, without
having to worry about wrapping and horisontal scrolling.
It can be hard to come up with good short names, but you can also
trade indentation levels for a new function.
But while an 80 character limit works well for me, it might not for
others, and I am not sure whether or not it should be generally
recommended style (indecision ftw).
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
evins...@gmail.com
evins...@gmail.com
use for readable lisp indentation style is, imagine the parentheses
are invisible; now use indentation to convey the grouping of
expressions and subexpressions. In general, indent parallel expression
to the same level; indent subsidiary expressions to a deeper level.
Break those rules when it will make the code clearer and more
readable.
let foo bar
baz grault
some-hairy-expression-containing-foo-and-baz
let foo bar
baz some-function
some-subexpression-containing-hairy-code
some-other-expression
some-subexpression-of-the-previous-line
another-parallel-subexpression
something-that-comes-after-the-previous-expression
Use spaces. Tabs are evil, because every editor does something
different with them, and indentation is meaningful.