7 ms·

I generally agree, but max line length being so high you have to horizontally scroll while reading code is very detrimental to productivity.

• appellations 1y ago
  I forget there are people who don’t configure softwrap in their text editor. Some languages (java) really need the extra horizontal space if you can afford it and aren’t too hard to read when softwrapped.
• forrestthewoods 1y ago
  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
    • 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.
• jitl 1y ago
  every editor can wrap text these days. good ones will even indent the wrapped text properly
  • giveita 1y ago
    Thats a slippery slope towards storing semantics and displaying locally preferred syntax ;)
    • rightbyte 1y ago
      Is this a subtle pro-tab pinch?
    • jitl 1y ago
      I prefer storing plain text and displaying locally preferred syntax, to a degree. With some expressions, like lookup tables or bit strings, hand wrapping and careful white space use is the difference between “understandable and intuitive” and “completely meaningless”. In JS world, `// prettier-ignore` above such an expression preserves it but ideally there’s a more universal way to express this.
    • NL807 1y ago
      And the bikeshedding has begun...
      • virtue3 1y ago
        was going to say the same thing. Boy that was fast.
      • giveita 1y ago
        What's the nuclear reactor in this analogy?
        • pferde 1y ago
          That the values could have been extracted to an array of structs, and iterated over in a small cycle that calls the function for each set of values.
• elevation 1y ago
  Formatters eliminating long lines is a pet peeve of mine. About once every other project, some portion of the source benefits from source code being arranged in a tabular format. Long lines which are juxtaposed help make dissimilar values stand out. The following table is not unlike code I have written: setup_spi(&adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01); setup_spi(&eeprom, mode=SPI_10, rate=13, cs_control=CS_MUXED, cs=0x02); setup_spi(&mram, mode=SPI_10, rate=50, cs_control=CS_DIRECT, cs=0x08); Even if we add 4-5 more operational parameters, I find this arrangement much more readable than the short-line equivalent: setup_spi(&adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01); setup_spi(&eeprom, mode=SPI_10, rate=13, cs_control=CS_MUXED, cs=0x02); setup_spi(&mram, mode=SPI_10, rate=50, cs_control=CS_DIRECT, cs=0x08); Or worse, the formatter may keep the long lines but normalize the spaces, ruining the tabular alignment: setup_spi(&adc, mode=SPI_01, rate=15, cs_control=CS_MUXED, cs=0x01); setup_spi(&som_eeprom, mode=SPI_10, rate=13, cs_control=CS_MUXED, cs=0x02); setup_spi(&mram, mode=SPI_10, rate=50, cs_control=CS_DIRECT, cs=0x08); Sometimes a neat, human-maintained block of 200 character lines brings order to chaos, even if you have to scroll a little.
  • lambdaba 1y ago
    I agree, I'm very much against any line length constraint, it's arbitrary and word wrapping exists.
  • IlikeKitties 1y ago
    I'm suprised. I find the short-line version to be much better.
  • growse 1y ago
    //nolint
    • bloak 1y ago
      /* clang-format off */
  • VBprogrammer 1y ago
• tsimionescu 1y ago
  I am at the opposite end. Having any line length constraints whatsoever seems like a massive waste of time every time I've seen it. Let the lines be as long as I need them, and accept that your colleagues will not be idiots. A guideline for newer colleagues is great, but auto-formatters messing with line lengths is a source of significant annoyance.
  • Cthulhu_ 1y ago
    > auto-formatters messing with line lengths is a source of significant annoyance. Unless they have been a thing since the start of a project; existing code should never be affected by formatters, that's unnecessary churn. If a formatter is introduced later on in a project (or a formatting rule changed), it should be applied to all code in one go and no new code accepted if it hasn't passed through the formatter. I think nobody should have to think about code formatting, and no diff should contain "just" formatting changes unless there's also an updated formatting rule in there. But also, you should be able to escape the automatic formatting if there is a specific use case for it, like the data table mentioned earlier.
• jghn 1y ago
  I’d agree with you except for the trend over the last 10 years or so to set limits back to the Stone Age. For a while there we seemed to be settling on somewhere around 150 characters and yet these days we’re back to the 80-100 range.