Let’s say you have a YAML file and you want to represent an ordered sequence.

It looks like this (as per YAML 1.2):

All the items start on same vertical column.

The formatting is aligned with the semantics of this piece of YAML. It’s a data structure. It’s a list of items, which have equal standing as far as this list is concerned. The items are independent.

That is why when describing lists, vectors et al. we align all the items to start at the same column.

The same goes for vector literal in clojure:

In this case, the single space indentation for second and third item is there to offset the opening bracket and the effect it achieves is columnar aligment of the items. This is fine and it’s completely sensible, since it’s a vector of independent and equal elements.

Clojure Style Guide suggests the same formatting for function calls or operations instead of just vectors. This is where this thing goes off the rails:

This is simply wrong. It pretends that the first element of the list, the operation, does not have a special semantic, when it clearly does!

The first element of the list is special, it’s the operation or function.

Prior argument would be reason enough not to use this formatting scheme, but to make things worse, there are many many exceptions to this rule special forms like if, any control macro, any binding macro etc…​ but not all macros.

It’s practically impossible to create an automatic formatter that would follow this code style because you’d need a database of third party macros and their correct formatting.

This is ironic given that the author is an author of a linter.

The question might arise: what about other older Lisps?

This other Scheme related style document provides the following rationale:

I don’t think that one additional space of indentation weakens visual vertical scanning, because the difference is too small for the argument to have some other symbol above it to confuse the issue or to make parenthesis confusing.

This argument is especially suspect since we know that there exist forms with 2 space indentation in the same standard.

And for the second rule I don’t agree with:

Programming Lisp with an 80 character budget is like programming C with a 60 character budget.

There are commonly used constructs that don’t increase level of indentation in Algol languages like C, but it does in Lisp, most obvious is introducing a local variable.

In C it would be simply:

No additional indentation was introduced. Here’s Clojure:

A let statement increases indentation.

In general, S-expressions introduce more indentation than general C-style language code, hence they need more horizontal space.

So what does one do when you reach the 80 column limit?

One way is to break the line. The established formatting rules make it so this really doesn’t free up much space.

Another approach is to factor out the nested expressions into functions.

This has severe shortcomings.

Another alternative is to break up expressions into let bindings instead of functions. This still has a problem with succinct names for similar values:

When the expression breaks down into subexpressions which are of type previous value but with slight twist, it becomes really hard to come up with names.

The only really adequate solution is threading macros, but those don’t work that well in all situations.

The main reason why we have people advocating for this limit in 2019 is that some people work in Emacs on a single laptop monitor, and then they split that single monitor down into multiple text buffers, which end up being really small so 80 character limit is needed by them.

I work with multiple large monitors and most of my screen is empty in these codebases.

But why does the industry need to adjust to the lowest common denominator? Imagine professional photographers adjusting everything to work with the smallest lenses because there are people who use that.