(Community Standards)
As with any Lisp ever created
, Clojure has recently been infected with talk of
alternative layout styles of closing
(and in some cases
, open
)
parentheses
. While I am in danger of succumbing to the
Clojure extension to Wadler's Law (1)
, I take such a chance in order to prove a point
. You see
, there are numerous reasons to practice
alternative placements of parentheses
, but they basically all boil down to
:
1) familiarity
2) personal aesthetics
. Likewise
, the primary reason to adhere to a community
standard of paren placement is inherent in
the word "community"
-- it's good sense to present a styling that %99%
of the community will instantly feel
comfortable viewing and contributing to
. The problem with the personal aesthetic
*and* the community standard is that neither
one defines a style that is universally
intuitive (2)
. I think people arguing both sides miss this
point and tend to insist that the style they
follow is "the best" and "most logical"
, when they instead should realize that each of
these statements contain an implicitly qualifying
, "FOR ME"
. However
, while your personal style is tailored to
your own foibles
, the community standard aims
at a mythical every-man (and woman)
. Both styles become invisible with repeated use
, but the advantage of a community standard is that
it is invisible for the majority
, while your personal style puts you on an island
where anyone else is instantly repelled
. The result of this repulsion is two-fold
:
1) You lose credibility (whether it's
unfounded or not is irrelevant)
2) People refuse to spend much time
looking at your code
. The end result in either case is the same
, like the proverbial desert island
, your project will suffer from a lack of
contributors
. People only have so many hours (3) in a day
, and are less likely to spend their time helping
to fix your code if they also have to attempt to
decipher your personal aesthetic
. Of course
, if you never plan to subject the world to your
code (4)
, then by all means put the parens wherever you
like
. It's purely a pragmatic assessment
. Perhaps your style is vastly superior
, but the general fact is that people will not
adopt it unless you crank out phenomenal code
and become a geek icon
(a-la
Torvalds
)
. This will be my only attempt to make sense of
the "placement-wars"
, so I hope my message is loud and clear
-- thankfully I used THE optimal formatting scheme
!
(1) http://blog.fogus.me/2010/07/12/wadlers-law-extended-to-clojure/
(2) If such a thing could ever exist in relation to humanity.
(3) It took Chris Houser to really make this point clear to me. Thank you.
(4) Companies like Google go out of their way to enforce a uniform community standard throughtout their entire codebase. The reason for this is that they established an environment where the cost of developer transition can occur unfettered by the nuances of code structuring. It’s difficult enough to dive into a new codebase fresh, and exponentially so when everything looks so weird (relatively).
10 Comments, Comment or Ping
Paul Stadig
You missed two commas in “However, while your personal style is tailored to your own foibles, the community standard aims at a mythical every-man (and woman)”
For shame! :)
Aug 30th, 2010
fogus
@Paul
You’re correct. But who’s to say that wasn’t part of the aesthetic? ;-)
Aug 30th, 2010
tonyl
I agree with your point 100%. But what markup format are you showing us here with all those extra punctuation marks in the beginning of a line?
Aug 30th, 2010
fogus
@tonyl
I like to call it “Fogus’s awesome English language syntax correction”
Aug 30th, 2010
Simon Hawkin
I should confess I kind of like the style used in this essay, and I am sure I am not alone…
Personal stylistic preferences in the code formatting (which extend far beyond Clojure and Lisp family of languages) may help in presenting the programmer’s idea of the code structure. To me it feels almost like a domain-specific language, the domain being the visual representation of the program text. (Almost.)
Aug 30th, 2010
Benji York
Communication through layout. E. E. Cummings would be proud.
Aug 30th, 2010
Benji York
E. E. Cummings would be proud.
Aug 30th, 2010
msk
It’s really amazing that with all the other amazing advancements in code editors that this is still an issue. But it certainly IS an issue.
We need to accept that people are different, and settling for the “everyman” is sub-optimal when we have computers that can trivially tailor code for each individual.
Personally, I have very strong feelings about code formatting, but it seems that I am neither amongst the majority in my tastes, nor do I shine so brilliantly that the masses will follow whatever I do (nor would I want them to – each should do what is most effective form themselves).
Formatting should not even be associated with a code file. Formatting should strictly be an editor setting. I think that when code is saved to a file, it should be compressed to the minimum size permitted by the language syntax.
Coding practices and standards are a related issue that is not so easily solved, and while different people have different tastes, I certainly do agree that community standards are important.
Aug 30th, 2010
Tim
msk: That sounds all well and good, and you’re probably a great mediator. :-) The problem with it is that often, the desired formatting isn’t strictly rule-based. Imagine what a typical code formatter would do with Duff’s Device, especially before it was generally known by the world. (Or what a word processor’s corrections would do to e e cummings.)
This is especially a problem in Lisp, which tends to break many of the rules that other languages keep sacred. A Java programmer, for example, will have separate syntax entirely for code and data, but in Lisp I create new syntactical structures all day long. How is my poor editor supposed to keep up with what exactly means what? Even Emacs has trouble, sometimes.
Nov 29th, 2010
Tim
I disagree with the remark that style will stop people from following you “unless you crank out phenomenal code and become a geek icon”.
I’ve contributed to countless open-source (and closed-source) projects over the years — and avoided contributing to others. Formatting style has never once been a cause for me to decide whether to hack on something, or not. I have never seen a coding style (except once, on dailywtf) that was so bad I couldn’t deal with it. It’s simply not an issue.
It’s not even like “it’s easy enough I can deal with it”. It doesn’t even register, no matter where the braces and newlines are. It’s like somebody asking where the “washroom” is: I’d just answer, not stop to think “oh he’s speaking Canadian English! I must respond in kind!”.
Issues that have actually made me not want to contribute: wrong programming language (too low-level), wrong natural language (e.g., all the comments were broken German, and my German isn’t that good), complete lack of documentation, lead maintainer was a jerk (online, in person, or both), architecture was just plain lousy (e.g., build system was both non-standard, and impossible to figure out).
But I’ve never seen a half-way decent program that I’ve not wanted to contribute to, due to some stylistic idiosyncrasies. As you note, some of the most famous and successful programmers in the world have stylistic idiosyncrasies. As you say, it’s a pragmatic assessment. Who’d want to say they passed on being the #2 programmer on the next Linux kernel because the next Linus used the ‘wrong’ number of spaces?
Nov 29th, 2010
Reply to “(Community Standards)”