5 ms·

isn't it true that the lisp community is more tolerate of horizontal space than most subsets of programmer? That, plus the fact i haven't coded on a 4:3 monito

by dmead 8y ago

isn't it true that the lisp community is more tolerate of horizontal space than most subsets of programmer? That, plus the fact i haven't coded on a 4:3 monitor since ~2002 makes me thing this is not helpful. The overuse of newlines in coding standards is... a useless exercise.

jetrink 8y ago
I still like to constrain line length, because having two source files (or a source file and a REPL) side-by-side on the same monitor is so useful. The trade-off of avoiding long lines is a small price to pay. I recognize that most people like to have one file per monitor though.
notduncansmith 8y ago
I don't know about the wider Lisp community, but I think Clojure is much easier to edit and more aesthetically pleasing when arranged in well-newlined blocks <=80 chars wide. Constraining line length is great for readability. The benefits are similar to those gained by limiting prose line length, and sentence length. Think of a long line of code as having similar traversal characteristics to a linked list. This requires more memory for comprehension, and is hard to search. Now compare this to a newlined block of code, which resembles a richer data structure that spatially colocates relevant elements. It's a difference that matters a lot.
- kazinator 8y ago
  > The benefits are similar to those gained by limiting prose line length, and sentence length. Not really; prose doesn't indent with increasing nesting, so line length in prose actually means that many non-whitespace characters to scan. > Now compare this to a newlined block of code, which resembles a richer data structure that spatially colocates relevant elements. Nobody writes huge lines in Lisps; but the indentation can get out of hand in large functions. So you have this neat block that spatially colocates relevant elements, but has 150 columns of whitespace on the left, which creates a navigation challenge that is different from the problem of scanning a long line. If you combat this by simpy constraining the column length, then what happens is this problem (cramped expressions (butting up to 80 col limit)) You have little recourse but to break it up into smaller functions (perhaps some of them nested in the parent).
  - notduncansmith 8y ago
    Ahh, so you're more concerned with indentation than huge lines of code. Makes sense. > You have little recourse but to break it up into smaller functions (perhaps some of them nested in the parent). Generally this type of factoring is a good thing for the codebase, and a very natural part of the development process in Clojure.
  - dkersten 8y ago
    > Not really; prose doesn't indent with increasing nesting Clojure lines increase in length as they increase in nesting, but without increasing nesting, they don't typically get particularly long[1], unless you have very long argument lists or very long names. So, the key is to reduce nesting (which helps comprehension anyway) and Clojure has plenty of tools to help with that: you can use ->, ->>, as->, some->, or you can bind sub-expressions to names using let/when-let/etc. There's no need to split code into smaller functions unless it makes sense to do so (eg for code reuse or semantically). [1] 2-space indents help keep indents from being crazy wide without crazy nesting. The only place where I often find lines getting too long is let-blocks with aligned expressions and long variable names: (let [this-name-is-too-long (some-code-here (uh-oh this is getting long) ...
    - OliverM 8y ago
      ] )) Had to close those parens to stop the mental itch!
      - dkersten 8y ago
        Hah! But but but I did close them (implicitly, as part of the "...")
dkersten 8y ago
> The overuse of newlines in coding standards is... a useless exercise. My clojure code is more vertically compact (despite sticking to 80-column lines and avoiding deep nesting) than a lot of C++ code I see out there: if (condition) { // wasted line some = code(here); } // another wasted line? // sometimes a blank line here too if (another condition) { ... The Java convention at least wastes a tiny bit less vertical space: if (condition) { some = code(here); } if (another condition) { ... In Clojure I have the same, but without the trailing closing brace. I insert blank lines if I need to visually break the code up or if its really unrelated from the previous line, but its up to me when to apply it based on when it makes sense to do so, not just because the naming standard says so. (if condition (some code here)) (if another-condition ...) In reality, I'd of course use when and if the body is trivial then I may even simply write (when condition trivial-body) as one line. As long as it won't go over 80 characters.

by dmead 8y ago

jetrink 8y ago

I still like to constrain line length, because having two source files (or a source file and a REPL) side-by-side on the same monitor is so useful. The trade-off of avoiding long lines is a small price to pay. I recognize that most people like to have one file per monitor though.

notduncansmith 8y ago

I don't know about the wider Lisp community, but I think Clojure is much easier to edit and more aesthetically pleasing when arranged in well-newlined blocks <=80 chars wide. Constraining line length is great for readability. The benefits are similar to those gained by limiting prose line length, and sentence length. Think of a long line of code as having similar traversal characteristics to a linked list. This requires more memory for comprehension, and is hard to search. Now compare this to a newlined block of code, which resembles a richer data structure that spatially colocates relevant elements. It's a difference that matters a lot.

kazinator 8y ago
> The benefits are similar to those gained by limiting prose line length, and sentence length. Not really; prose doesn't indent with increasing nesting, so line length in prose actually means that many non-whitespace characters to scan. > Now compare this to a newlined block of code, which resembles a richer data structure that spatially colocates relevant elements. Nobody writes huge lines in Lisps; but the indentation can get out of hand in large functions. So you have this neat block that spatially colocates relevant elements, but has 150 columns of whitespace on the left, which creates a navigation challenge that is different from the problem of scanning a long line. If you combat this by simpy constraining the column length, then what happens is this problem (cramped expressions (butting up to 80 col limit)) You have little recourse but to break it up into smaller functions (perhaps some of them nested in the parent).
- notduncansmith 8y ago
  Ahh, so you're more concerned with indentation than huge lines of code. Makes sense. > You have little recourse but to break it up into smaller functions (perhaps some of them nested in the parent). Generally this type of factoring is a good thing for the codebase, and a very natural part of the development process in Clojure.
- dkersten 8y ago
  > Not really; prose doesn't indent with increasing nesting Clojure lines increase in length as they increase in nesting, but without increasing nesting, they don't typically get particularly long[1], unless you have very long argument lists or very long names. So, the key is to reduce nesting (which helps comprehension anyway) and Clojure has plenty of tools to help with that: you can use ->, ->>, as->, some->, or you can bind sub-expressions to names using let/when-let/etc. There's no need to split code into smaller functions unless it makes sense to do so (eg for code reuse or semantically). [1] 2-space indents help keep indents from being crazy wide without crazy nesting. The only place where I often find lines getting too long is let-blocks with aligned expressions and long variable names: (let [this-name-is-too-long (some-code-here (uh-oh this is getting long) ...
  - OliverM 8y ago
    ] )) Had to close those parens to stop the mental itch!
    - dkersten 8y ago
      Hah! But but but I did close them (implicitly, as part of the "...")

dkersten 8y ago

> The overuse of newlines in coding standards is... a useless exercise. My clojure code is more vertically compact (despite sticking to 80-column lines and avoiding deep nesting) than a lot of C++ code I see out there: if (condition) { // wasted line some = code(here); } // another wasted line? // sometimes a blank line here too if (another condition) { ... The Java convention at least wastes a tiny bit less vertical space: if (condition) { some = code(here); } if (another condition) { ... In Clojure I have the same, but without the trailing closing brace. I insert blank lines if I need to visually break the code up or if its really unrelated from the previous line, but its up to me when to apply it based on when it makes sense to do so, not just because the naming standard says so. (if condition (some code here)) (if another-condition ...) In reality, I'd of course use when and if the body is trivial then I may even simply write (when condition trivial-body) as one line. As long as it won't go over 80 characters.