38 ms·

Define high? I think 120 is pretty reasonable. Maybe even as high as 140. Log statements however I think have an effectively unbounded length. Nothing I hate m

Define high? I think 120 is pretty reasonable. Maybe even as high as 140. Log statements however I think have an effectively unbounded length. Nothing I hate more than a stupid linter turning a sprinkling of logs into 7 line monsters. cargo fmt is especially bad about this. It’s so bad.

skinner927 1y ago
I still prefer 80. I won’t (publicly) scoff at 100 though. IMO 120 is reasonable for HTML and Java, but that’s about it. Sent from my 49” G9 Ultrawide.
- forrestthewoods 1y ago
  Ugh. 80 is the worst. For C++ it’s entirely unreasonable. I definitely can not reconcile “linters make code easier to read” and “80 width is good”. Those are mutually exclusive imho. What I actually want from a linter is “120, unless the trailing bits aren’t interesting in which case 140+ is fine”. The ideal rule isn’t hard and fast! It’s not pure science. There’s an art to it.
- Joker_vD 1y ago
  Give a try to 132 mode, maybe? It was the standard paper width for printouts since, well, forever.
  - psychoslave 1y ago
    Printing industry have not been anything close to forever, even writing is relatively novel compared to human spoken languages. All that said, I'm interested with this 132 number, where does it come from?
    - bloak 1y ago
      The IBM 1403 line printer, apparently.
    - dcminter 1y ago
      Printers aside the VT220 terminal from DEC had a 132 column mode. Probably it was aping a standard printer column count. Most of the time we used the 80 column mode as it was far more readable on what was quite a small screen.
      - guenthert 1y ago
        Not only a small screen by modern standards, but the hardware lacked the needed resolution. The marketing brochure claims a 10x10 dot matrix. That will be for the 80 column mode. That works out to respectable 800 pixel horizontally, barely sufficient 6x10 pixel in 132 column mode. There was even a double-high, double-width mode for easier reading ;-) Interesting here perhaps is that even back then it was recognized, that for different situations, different display modes were of advantage.
        dcminter 1y ago
        > There was even a double-high, double-width mode for easier reading I'd forgotten that; now that waa a fugly font. I don't think anyone ever used it (aside from the "Setup" banner on the settings screen) I think the low pixel count was rather mitigated by the persistence of phospher though - there's reproductions of the fonts that had to take this into account; see the stuff about font stretching here: https://vt100.net/dec/vt220/glyphs https://vt100.net/dec/vt220/glyphs
    - Joker_vD 1y ago
      "Since forever" as in, "since the start of electronic computing"; we started printing the programs out on paper almost immediately. The 132 columns comes from the IBM's ancient line printers (circa 1957); most of other manufacturers followed the suit, and even the glass ttys routinely had 132-column mode (for VT100 you had to buy a RAM extension, for later models it was just there, I believe). My point is, most of the people did understand, back even in the sixties, that 80-columns wide screen is tiny, especially for reading the source code.
  - balamatom 1y ago
    That's actually just weirdly specific enough to be worth a shot.
- typpilol 1y ago
  That's literally my setup everywhere. 120 for html/java/JavaScript and 80 elsewhere. Really suites each language imo Although I could probably get away with 80, habit to use tailwind classes can get messy compared to 120
  - Cthulhu_ 1y ago
    Caveat, my personal experience is mainly limited to JS/TS, Java, and associated languages. 120 is fine for most use cases; I've only seen 80 work in Go, but that one also has unwritten rules that prefer reducing indentation as much as possible; "line-of-sight programming", no object-oriented programming (which gives almost everything a layer of indentation already), but also it has no ternary statements, no try/catch blocks, etc. It's a very left-aligned language, which is great for not unnecessarily using up that 80 column "budget".
- anilakar 1y ago
  But a 49" ultrawide is just two 27" monitors side by side. :-)
  - account42 1y ago
    Better yet, its three monitors with more reasonable aspect ratios side by side. 16:9 is rarely what you want for anything that is mainly text.
- guenthert 1y ago
  Obviously 100 is the right choice. https://en.wikipedia.org/wiki/Line_length#cite_note-dykip-8 https://en.wikipedia.org/wiki/Line_length#cite_note-dykip-8
setopt 1y ago
It’s tricky to find an objective optimum. Personally I’ve been happy with up to 100 chars per line (aim for 80 but some lines are just more readable without wrapping). But someone will always have to either scroll horizontally or wrap the text. I’m speaking as someone who often views code on my phone, with a ~40 characters wide screen. In typography, it’s well accepted that an average of ~66 chars per line increases readability of bulk text, with the theory being that short lines require you to mentally «jump» to the beginning of the next line frequently which interrupts flow, but long lines make it harder to mentally keep track of where you are in each line. There is however a difference between newspapers and books, since shorter ~40-char columns allows rapid skimming by moving your eyes down a column instead of zigzagging through the text. But I don’t think these numbers translate directly to code, which is usually written with most lines indented (on the left) and most lines shorter than the maximum (few statements are so long). Depending on language, I could easily imagine a line length of 100 leading to an average of ~66 chars per line.
- fmbb 1y ago
  > the theory being that short lines require you to mentally «jump» to the beginning of the next line frequently which interrupts flow, but long lines make it harder to mentally keep track of where you are in each line. In my experience, with programming you rarely have lines of 140 printable characters. A lot of it is indentation. So it’s probably rarely a problem to find your way back on the next line.
- forrestthewoods 1y ago
  I don’t think code is comparable. Reading code is far more stochastic than reading a novel. For C/C++ headers I absolutely despise verbose doxygen bullshit commented a spreading relatively straightforward functions across 10 lines of comments and args. I want to be able to quickly skim function names and then read arguments only if deemed relevant. I don’t want to read every single word.
layer8 1y ago
100 is the sweet spot, IMO. I like splitting long text as in log statements into appropriate source lines, just like you would a Markdown paragraph. As in: logger.info( "I like splitting long text as in log statements " + "into ” + suitablelAdjective + " source lines, " + "just like you would a Markdown paragraph. " + "As in: " + quine); I agree that many formatters are bad about this, like introducing an indent for all but the first content line, or putting the concatenation operator in the front instead of the back, thereby also causing non-uniform alinkemt of the text content.
- saagarjha 1y ago
  This makes it really annoying to grep for log messages. I can't control what you do in your codebase but I will always argue against this the ones I work on.
  - layer8 1y ago
    I haven’t found this to be a problem in practice. You generally can’t grep for the complete message anyway due to inserted arguments. Picking a distinctive formulation from the log message virtually always does the trick. I do take care to not place line breaks in the middle of a semantic unit if possible.
    - saagarjha 1y ago
      Yes, I find the part of the message that doesn't have interpolated arguments in it. The problem is that the literal part of the string might be broken up across lines.
      - bogomog 1y ago
        And to add to this, you rarely need to read a log message when just visually scanning code, its fine going off the screen.
- maleldil 1y ago
  Nitpick: this looks like Python. You don't need + to concatenate string literal. This is the type of thing a linter can catch.

skinner927 1y ago

I still prefer 80. I won’t (publicly) scoff at 100 though. IMO 120 is reasonable for HTML and Java, but that’s about it. Sent from my 49” G9 Ultrawide.

forrestthewoods 1y ago
Ugh. 80 is the worst. For C++ it’s entirely unreasonable. I definitely can not reconcile “linters make code easier to read” and “80 width is good”. Those are mutually exclusive imho. What I actually want from a linter is “120, unless the trailing bits aren’t interesting in which case 140+ is fine”. The ideal rule isn’t hard and fast! It’s not pure science. There’s an art to it.
Joker_vD 1y ago
Give a try to 132 mode, maybe? It was the standard paper width for printouts since, well, forever.
- psychoslave 1y ago
  Printing industry have not been anything close to forever, even writing is relatively novel compared to human spoken languages. All that said, I'm interested with this 132 number, where does it come from?
  - bloak 1y ago
    The IBM 1403 line printer, apparently.
  - dcminter 1y ago
    Printers aside the VT220 terminal from DEC had a 132 column mode. Probably it was aping a standard printer column count. Most of the time we used the 80 column mode as it was far more readable on what was quite a small screen.
    - guenthert 1y ago
      Not only a small screen by modern standards, but the hardware lacked the needed resolution. The marketing brochure claims a 10x10 dot matrix. That will be for the 80 column mode. That works out to respectable 800 pixel horizontally, barely sufficient 6x10 pixel in 132 column mode. There was even a double-high, double-width mode for easier reading ;-) Interesting here perhaps is that even back then it was recognized, that for different situations, different display modes were of advantage.
      - dcminter 1y ago
        > There was even a double-high, double-width mode for easier reading I'd forgotten that; now that waa a fugly font. I don't think anyone ever used it (aside from the "Setup" banner on the settings screen) I think the low pixel count was rather mitigated by the persistence of phospher though - there's reproductions of the fonts that had to take this into account; see the stuff about font stretching here: https://vt100.net/dec/vt220/glyphs https://vt100.net/dec/vt220/glyphs
  - Joker_vD 1y ago
    "Since forever" as in, "since the start of electronic computing"; we started printing the programs out on paper almost immediately. The 132 columns comes from the IBM's ancient line printers (circa 1957); most of other manufacturers followed the suit, and even the glass ttys routinely had 132-column mode (for VT100 you had to buy a RAM extension, for later models it was just there, I believe). My point is, most of the people did understand, back even in the sixties, that 80-columns wide screen is tiny, especially for reading the source code.
- balamatom 1y ago
  That's actually just weirdly specific enough to be worth a shot.
typpilol 1y ago
That's literally my setup everywhere. 120 for html/java/JavaScript and 80 elsewhere. Really suites each language imo Although I could probably get away with 80, habit to use tailwind classes can get messy compared to 120
- Cthulhu_ 1y ago
  Caveat, my personal experience is mainly limited to JS/TS, Java, and associated languages. 120 is fine for most use cases; I've only seen 80 work in Go, but that one also has unwritten rules that prefer reducing indentation as much as possible; "line-of-sight programming", no object-oriented programming (which gives almost everything a layer of indentation already), but also it has no ternary statements, no try/catch blocks, etc. It's a very left-aligned language, which is great for not unnecessarily using up that 80 column "budget".
anilakar 1y ago
But a 49" ultrawide is just two 27" monitors side by side. :-)
- account42 1y ago
  Better yet, its three monitors with more reasonable aspect ratios side by side. 16:9 is rarely what you want for anything that is mainly text.
guenthert 1y ago
Obviously 100 is the right choice. https://en.wikipedia.org/wiki/Line_length#cite_note-dykip-8 https://en.wikipedia.org/wiki/Line_length#cite_note-dykip-8

setopt 1y ago

It’s tricky to find an objective optimum. Personally I’ve been happy with up to 100 chars per line (aim for 80 but some lines are just more readable without wrapping). But someone will always have to either scroll horizontally or wrap the text. I’m speaking as someone who often views code on my phone, with a ~40 characters wide screen. In typography, it’s well accepted that an average of ~66 chars per line increases readability of bulk text, with the theory being that short lines require you to mentally «jump» to the beginning of the next line frequently which interrupts flow, but long lines make it harder to mentally keep track of where you are in each line. There is however a difference between newspapers and books, since shorter ~40-char columns allows rapid skimming by moving your eyes down a column instead of zigzagging through the text. But I don’t think these numbers translate directly to code, which is usually written with most lines indented (on the left) and most lines shorter than the maximum (few statements are so long). Depending on language, I could easily imagine a line length of 100 leading to an average of ~66 chars per line.

fmbb 1y ago
> the theory being that short lines require you to mentally «jump» to the beginning of the next line frequently which interrupts flow, but long lines make it harder to mentally keep track of where you are in each line. In my experience, with programming you rarely have lines of 140 printable characters. A lot of it is indentation. So it’s probably rarely a problem to find your way back on the next line.
forrestthewoods 1y ago
I don’t think code is comparable. Reading code is far more stochastic than reading a novel. For C/C++ headers I absolutely despise verbose doxygen bullshit commented a spreading relatively straightforward functions across 10 lines of comments and args. I want to be able to quickly skim function names and then read arguments only if deemed relevant. I don’t want to read every single word.

layer8 1y ago

100 is the sweet spot, IMO. I like splitting long text as in log statements into appropriate source lines, just like you would a Markdown paragraph. As in: logger.info( "I like splitting long text as in log statements " + "into ” + suitablelAdjective + " source lines, " + "just like you would a Markdown paragraph. " + "As in: " + quine); I agree that many formatters are bad about this, like introducing an indent for all but the first content line, or putting the concatenation operator in the front instead of the back, thereby also causing non-uniform alinkemt of the text content.

saagarjha 1y ago
This makes it really annoying to grep for log messages. I can't control what you do in your codebase but I will always argue against this the ones I work on.
- layer8 1y ago
  I haven’t found this to be a problem in practice. You generally can’t grep for the complete message anyway due to inserted arguments. Picking a distinctive formulation from the log message virtually always does the trick. I do take care to not place line breaks in the middle of a semantic unit if possible.
  - saagarjha 1y ago
    Yes, I find the part of the message that doesn't have interpolated arguments in it. The problem is that the literal part of the string might be broken up across lines.
    - bogomog 1y ago
      And to add to this, you rarely need to read a log message when just visually scanning code, its fine going off the screen.
maleldil 1y ago
Nitpick: this looks like Python. You don't need + to concatenate string literal. This is the type of thing a linter can catch.