- Code is not prose. It's not read like a book so it's not clear that an "ideal measure for continuous text" is at all relevant.

- Most lines are short even if the limit is more than 80 characters, so you're unlikely to accidentally shift up or down after reading a long line.

- Even if there turns out to be some benefit for reading code based on Saccades, that means nothing unless you can make some quantitative comparison with the other advantages and disadvantages of a longer line length.

For me it's not just the length of the line but the level of indentation. I think wide indents are good for readability, so if you're using standard tabs and also sticking to 80 columns as a hard limit then you have only 64 characters to work with at two levels of indentation. Excessive indentation is a clue that you may want to refactor, but two levels is pretty common.

80 charcters starting at the point of indentation is more reasonable. At two levels of indenting, you might get out to 96 characters, which still fits comfortably in most GUI terminal windows.

W is the bare minimum, it’s a function and a conditional or loop, 3 or 4 is pretty common.

The biggest problem with short lines isn't even the line length, it's that it encourages stupid variable names in order to keep things on one line. Silly abbreviations that no one new to the code can figure out are the bane of my existence.

Why does code have to be "read like a book" to be considered "continuous text"? Of course code is continuous text.

No it's not: a book is generally read from cover to cover (at least fiction) while code is split amongst various files. One is free to read them in any order, which is the opposite of continuous text.

And like with files, you are also free to read chapters of a book in any order. But files have little to do with lines, no? Of course a function definition in every sane language is continuous text, even though you "are free" to read it backwards or starting in the middle.

That's for books.

When reading code, I'd rather see a single statement on one line, rather that break it at 2 lines because it passed some ancient 80 char limit...

Thank you. I was looking for this.

I don't care if a line needs to be 180 chars if it starts with log.debug. Just like searching, I read my code globally based on the first 10-20 chars. If I need details on a line, I'll read the whole line.

I do however put chained methods on new lines, because they are often a new statement.

And I use 4 spaces for indent, because my IDE is smart enough, it is in my programming language guidelines, and that's what my comapny uses.

I'd rather not have that statement more than 80 char long; that might be a one liner where many things are happening, in case there _is_ value is breaking it up, or maybe the variable names are too long, not helping readability.

Long variable names can cause long lines.

So can simple arithmetic that would be worse with intermediate values.

"ancient" doesn't mean wrong. Round wheels are ancient, it doesn't mean we should switch to the square wheels.

>Round wheels are ancient, it doesn't mean we should switch to the square wheels.

No, but it means we better use rubber wheels, not stone ones...

It doesn't mean right either, and the person you are responding to gave specific reasons why they prefer longer.

So it’s almost as if the “ancient” qualifier was useless.

Well it was clearly meant to imply that the reason we are using it is merely tradition, and that there was a reason a long time ago that no longer applies.

It was intended to mean "relavent in old times".

And we all use 80-column wheels because that's what the ancients used, by Zeus!

Oh wait, we use wheels sized for their use cases…

Do we, though?

http://www.naciente.com/essay94.htm

We also shouldn’t burn people deemed witches at the stake. Being ancient doesn’t make it right, either.

Even PEP8 says "Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the line length limit up to 99 characters, provided that comments and docstrings are still wrapped at 72 characters."

> it is okay to increase the line length limit up to 99 characters

PEP8 is strongly biased towards making code readable, and has helped a generation of programmers start thinking about readability when coding. The line length limit, though, is one of the few parts of PEP8 that introduced defects as a practice. Holding to 80 characters causes:

* string concatenation bugs from breaking up long strings

* errors in expressions broken up into multiple expressions just to fit

* bias to use shorter variable names

My favorite part of PEP8 was the warning about "foolish consistency".

Are we supposed to be reading the PEPs?

If you care about the reasoning behind whatever feature they are implementing.

Comments suffer even more from line length limit. I saw it many times when a comment is changed and then all following lines get rewrapped.

> I take the even more draconian approach of wrapping to 72 columns when writing comments, after the fashion of PEP 8.[3]

Which also happens to be how Linus wrapped the lines of this particular email.

Plaintext email is wrapped to 72, that's in the RFC - Linus didn't have much choice there.

Sure did:

> Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.

https://datatracker.ietf.org/doc/html/rfc5322#section-2.1.1

https://www.arp242.net/email-wrapping.html

I think I heard somewhere that the studies about line length don’t actually give very strong evidence in favour of short lines. On the other hand, I don’t have a source for that. Do you know if they are any good or is this just repeating common wisdom?

Some arguments in favour of longer lines would be:

- monospaced fonts are relatively wide so the line is not long in terms of the number of characters

- there can be a lot of non-length on the left hand side due to indentation (especially in Linux where tabs are wide)

- programmers are relatively literate and so might perform better than average at finding the start of the line

- editor features like line highlighting can help to find the line

- source code has a very ragged edge and so it is easier to find the start of the line than in dense prose.

- magazines or their readers prefer narrow columns for stylistic reasons. E.g. newspapers sometimes have very narrow columns that lead to intraword spacing that makes things hard to read

1) has tenuous relevance at best

2) The 80 or 66 char or whatever is literally a non-science driven designer rule of thumb that's actually the opposite conclusion from results of actual research into the issue (granted it's not exactly a deeply studied niche but there is research).

Arbitrary line breaking is ugly and a unnecessary source of errors. I avoid writing lines longer than 80 chars but in some cases it feels better and more ergonomic/readable to exceed it.

It depends. This is not an unbroken rule.

E.g. if you have 4 long lines all following the same pattern with minor modifications, the best way to both scan quickly and avoid bugs is to write them on their own line fully and align the common parts vertically.

Splitting each line into smaller parts for the sake of "vertical scanning" actually achieves exactly the opposite in this case.

Book lines are not indented at different nested levels while code is. So, unless your line limit is 72char+indentation, it makes little sense to follow this deeply cumbersome policy which will result in developers making single letters for all variables and 2/3 letter function/method names.

When "visually scanning" code, in 90% of the cases, only the first 10 characters matter anyway, so I fail to see your point. How often do you really need to grasp, say, all function arguments at once?

These opinions about readability "flow" using numbered footnotes strikes me as the height of irony, but that's me.