Pop Quiz!
Inside of what form (function/macro) is the println on the highlighted line located?
I don't know about you, but it takes me a while to figure that out.
Whereas in other languages I can usually rely on the indentation of code to understand its structure, with most Lisp formatting I often end up having to rely on the editor, like a crutch, to figure it out.
It's not just me. Lots of other people have the same issue. You may have heard people complain about Lisp's parenthesis. Some have called it a "parenthesis jungle" or a "parenthesis zoo." The historically poor readability of Lisp has nothing to do with parenthesis and everything to do with how they're used, or rather, abused. That is the underlying complaint.
Without the help of fancy editor tricks, the only hint at where the 'println' function is located are just a few spaces (often no more than two) that are separated by many lines of code. Lisp is the only language that I'm aware of where this happens.
To address this issue, people will often rely on their editors. Rainbow parenthesis, visible whitespace, and indentation guides are some of the editor features that attempt to address this issue. The problem though, is that these features aren't universally available across editors, nor are they available when the source code is viewed outside the editor, for example, on Github or some other code hosting site.
For every language I've used (other than Lisp), these editor tricks are completely unnecessary. The only time I've ever wanted rainbow-parenthesis support in my editor is while I'm looking at someone else's Lisp code.
In short:
The readability of your source code should not depend on the editor used to view it.
Lisp code can be just as readable as C, Ruby, and Python. The only thing stopping it is a community adopted convention, and I find that both sad and disappointing. Lisp is a beautiful language, so why make the structure of its code unreadable?
Let's have a look at that same block of code, this time formatted differently:
Now try the question again, in what function or macro is the highlighted line located in? Was it easier to answer this time?
This style is called "trailing your parenthesis," and is almost a taboo in the Lisp community. When asked why it is a taboo, you'll often hear answers like, "So that your parens don't end up lonely," and "It wastes lines!" In other words, no real reason. Parenthesis cannot get lonely, and the "importance" of "line count" is second to that of readability, at least I hope you'll agree.
What I found most puzzling and ironic about all of this is the irreverence that some Lispers treat parenthesis with. I've actually heard it said that parenthesis aren't even meant to be looked at. Sometimes this attitude and disdain for parenthesis is laughably obvious:
Nothing says "Get out of my sight" like piling up, or "stacking" parenthesis. I think the root of these feelings stem from the fact that parenthesis aren't used to help structure code, and when that's true, I can see how it's possible to feel that they're just "in the way."
They are treated as merely a necessary evil of the prefix syntax of function calling in Lisp.
This not only hurts readability but it hurts writability as well. Say I want to insert a new function call at the end of the body of a let call, only to discover that the closing parenthesis that I need to find is buried inside a paren stack. In this situation, you have to resort editor tricks, either the highlighting of matching parenthesis or a keystroke to jump to the matched paren. Those are some interesting hoops to jump through when in other languages it would be a simple point-and-click.
Detractors of "paren trailing" will say that you shouldn't use parenthesis to delimit scope because they are not scope delimiters (as braces are in C or Java). I think this is a very weak argument because they do delimit a scope. "Scope" does not only refer to variable scope, but it can also refer to the scope of a function call. Why treat parenthesis with such disrespect, and at the cost of the readability of your code, when by using them you are enhancing the readability of your code and giving them the respect they deserve?
No other language that I'm aware of stacks scope delimiters or has a community where the standard indentation width is two spaces wide, and where sometimes even a single space is considered acceptable.
Supposing this wasn't the case though.
What would it look like if C developers adopted this convention?
With apologies to the developers of Aquaria for this experiment, here's C++ code, showing Lisp-style stacking on the left, and what for C code is considered "normal" brace trailing on the right:
It's obvious which code is shorter, but which is easier to read and understand?
Conclusion
Code style is an almost religious affair, and debates over it can get heated.
I am not asking you to change your style if you're comfortable with paren stacking. I am merely explaining the reasons why some choose not to do so.
If you feel that parenthesis stacking actually improves the readability of your code, by all means, feel free to do so! However, "everyone else is doing it" is not a good reason to sacrifice the readability of your code.
(P.S. If you want trailing paren support in Emacs, I've written a simple 'lisp-indent-line' function you can use or build off of.)
Update: Another argument made is that "Lisp nests more than C" and therefore stacked parens are good. I think this is a poor excuse for a couple reasons:
- I've written and seen a lot of Lisp code. Most of it doesn't nest any more than regular C++/Java code. If your code is nesting a lot, it's likely an indication that you should be refactoring something out.
- Even if your code is nesting a lot, stacking your parens only worsens the readability, because when there's a jump back down several indentation levels, then it's a long way up to figure out what function you're in. Trailing your parenthesis gives you immediate local knowledge about what blocks of code you're outside of.
