You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the differences in Clojure from other Lisps that I have used is that frequently there are pairs of s-expressions without enclosing parentheses. These show up in binding vectors in let,when,if-let and their relatives. These pairs also show up in assoc, cond, condp, and case.
I like this syntactic clarity, but when writing code with other than single character local names in let, and with expressions for assoc, sometimes the pairs don't fit on the same line. In this case, the default approach is to simply place them all in line on the left. I find this difficult to read.
I have taken to indenting what would be the right-hand side of the pair (if it were on the same line) by 2 spaces so that the left-right relationship remains clear even if the two "sides" are on different lines.
; default approach
(let [local-value1 (expr1)
another-value (expr2)
third-value
(a (very (long (expression (that (doesnt (fit on) one line))))))
result-of-the-long-expression
(another (expression (that (is too long) for one) line))]
(result-of-the-long-expression))
; a possibly better alternative
(let [local-value1 (expr1)
another-value (expr2)
third-value
(a (very (long (expression (that (doesnt (fit on) one line))))))
result-of-the-long-expression
(another (expression (that (is too long) for one) line))]
(result-of-the-long-expression))
I have not seen anyone else do this, so I certainly can't say that this is idiomatic Clojure. However, I wanted to bring it up for discussion and consideration.
Of course, one approach is to not let this happen. But at least in my code, I sometimes have rather complex expressions on the right hand side of let binding vectors, as well as on both sides of assoc pair lists. To say nothing of cond and friends.
The text was updated successfully, but these errors were encountered:
@kkinnear I too hate seeing the default approach. In this case I usually just go over 80 lines (which I don't hink is such a big deal). I think your proposal would be a good one if we had the power to change the way lisp code got layed out across the community, but I doubt that is likely.
I like the idea, though it would be particularly tricky for editors since there is no way to distinguish between "this is a list of independent elements" and "this is a list of pairs of elements". I think that the proposal might be more appropriate for maps?
Instead of the default, I currently do this, and I know it's ugly :).
(let [local-value1 (expr1)
another-value (expr2)
third-value (a (very (long (expression
(that (doesnt (fit on) one line))))))
result-of-the-long-expression (another (expression
(that (is too long) for one) line))]
(result-of-the-long-expression))
One of the differences in Clojure from other Lisps that I have used is that frequently there are pairs of s-expressions without enclosing parentheses. These show up in binding vectors in
let
,when
,if-let
and their relatives. These pairs also show up inassoc
,cond
,condp
, andcase
.I like this syntactic clarity, but when writing code with other than single character local names in
let
, and with expressions forassoc
, sometimes the pairs don't fit on the same line. In this case, the default approach is to simply place them all in line on the left. I find this difficult to read.I have taken to indenting what would be the right-hand side of the pair (if it were on the same line) by 2 spaces so that the left-right relationship remains clear even if the two "sides" are on different lines.
I have not seen anyone else do this, so I certainly can't say that this is idiomatic Clojure. However, I wanted to bring it up for discussion and consideration.
Of course, one approach is to not let this happen. But at least in my code, I sometimes have rather complex expressions on the right hand side of
let
binding vectors, as well as on both sides ofassoc
pair lists. To say nothing ofcond
and friends.The text was updated successfully, but these errors were encountered: