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 4 days ago | parent | next [-]

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 4 days ago | parent | next [-]

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.

▲

guenthert 4 days ago | parent | prev | next [-]

Obviously 100 is the right choice.

https://en.wikipedia.org/wiki/Line_length#cite_note-dykip-8

▲

Joker_vD 4 days ago | parent | prev | next [-]

Give a try to 132 mode, maybe? It was the standard paper width for printouts since, well, forever.

▲

balamatom 4 days ago | parent | next [-]

That's actually just weirdly specific enough to be worth a shot.

▲

psychoslave 4 days ago | parent | prev [-]

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?

▲

Joker_vD 4 days ago | parent | next [-]

"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.

▲

dcminter 4 days ago | parent | prev | next [-]

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 4 days ago | parent [-]

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 4 days ago \| parent [-]
		> 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

▲

bloak 4 days ago | parent | prev [-]

The IBM 1403 line printer, apparently.

▲

typpilol 4 days ago | parent | prev | next [-]

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_ 4 days ago \| parent [-]
		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 4 days ago | parent | prev [-]

But a 49" ultrawide is just two 27" monitors side by side. :-)

	▲	account42 4 days ago \| parent [-]
		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.

▲ setopt 4 days ago | parent | prev | next [-]

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 4 days ago \| parent \| next [-]
		> 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 4 days ago \| parent \| prev [-]
		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 4 days ago | parent | prev [-]

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.

▲ forrestthewoods 3 days ago | parent | next [-]

Splitting log messages across lines like that is pure evil. Your punishment is death by brazen Bull. Sorry I don’t make the rules, just how it is. :(

▲ saagarjha 4 days ago | parent | prev | next [-]

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 4 days ago | parent [-]

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 4 days ago | parent [-]

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 3 days ago \| parent [-]
		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 4 days ago | parent | prev [-]

Nitpick: this looks like Python. You don't need + to concatenate string literal. This is the type of thing a linter can catch.

	▲	Sohcahtoa82 3 days ago \| parent \| next [-]
		IMO, implicit string concatenation is a bug, not a feature. I once made a stupid mistake of having a list of directories to delete: `directories_to_delete = ( "/some/dir" "/some/other/dir" ) for dir in directories_to_delete: shutil.rmtree(dir)` Can you spot the error? I somehow forgot the comma in the list. That meant that rather than creating a tuple of directories, I created a single string. So when the `for` loop ran, it iterated on individual characters of the string. What was the first character? "/" of course. I essentially did an `rm -rf /` because of the implicit concatenation.
	▲	layer8 3 days ago \| parent \| prev [-]
		It’s actually Java, where the “+” is necessary.