Agree. This 80 character limit stems from a time where terminals could only display comparatively few characters in a line, a limit we haven't had in decades as screen resolutions grew.

Another argument for shorters lines is that it is much harder for us to read any text when lines get too long. There's a reason why we read and write documents in portrait mode, not landscape.

But in sum, I don't think there's a need for creating a hard limit at the 80 character mark. Most code is not indented more than three or four times anyways, and most if not all languages allow you to insert newlines to make long expressions wrap. However, if you occasionally do need to go longer, I think that's completely fine and certainly better than having to bend around an arcane character limit.

> This 80 character limit stems from a time where terminals could only display comparatively few characters in a line, a limit we haven't had in decades as screen resolutions grew.

The 80 char rule has little to do with old monitors. Has to do with ergonomics, and is why any good edited and typeset book will have between 60 and 80 characters per line.

Exactly this. Open a novel and count the characters on a line; around 80 is readable as 500 years of typographic practice has determined. Two or three levels of indentation and that bumps the page width up a bit, still less than 100.

It is a fair point, but a book is 60 - 80 characters of dense prose line after line in thick paragraphs; it is not clear how this translates to lines of code.

In my personal experience (and of couse very subjective) it helps me a lit to have lines that fit the monitor, and I can have 2 parallel windows. Using 120 chars is for me just too much. I do think the golden rule of typography is “all rules can be broken if you know what you are doing”. For me is a soft limit. If splitting a line makes the code less readable, I do allow more. But frankly, that is the case of one in maybe 50k LOC

80 column punched cards were a very strong influence

As a part of ergonomics auditory, I really prefer 100-115 column soft limit for code editors, log viewing and console, because that’s how my single display dev setup works best. Otoh if I’m using IDEs with big sidebars like {X,VS}Code, then I need two displays and/or a full-width IDE anyway.

While I understand that this is an anecdotal preference, to me it doesn’t feel like the 80 column standard fits any modern dev workspace perfectly, tbh. (By modern I don’t mean “shiny”, just what we have now in hw/sw.)

Then let it be 80 characters from any whitespace on the left-hand side? I find it artificially awkward to have to wrap at a hard margin on the right-hand side. Surely you need to accommodate any indenting you're doing?

Take for example man pages, I find the very comfy to read. And they have generous margins on both sides. About indenting, I try to avoid deep nesting, usually 3 is a maximum, very rare to need more, if the code has to be easy to read.

Monitors are too new. Punch cards have 80 columns. I think this even pre-dates the use of teletypes with electronic computers.

It has to do with both and that's why my comment mentions both.

But then again, of course there is a reason why terminals (or punchcards) were made that way - presumably because of reading / writing ergonomics (besides technical reasons).

This rules readme isn't even less than 80 characters per line. You're saying we all had trouble reading it?

No rule is absolute. So you may have some line longer. Anyway I’m VERY skeptic that hardcoding URLs is a good idea at all.

Only hardcore cool URLs!

> Anyway I’m VERY skeptic that hardcoding URLs is a good idea at all.

They are talking about URLs in comments.

Oh. For comments I think would be ok, if it is a comment by itself, and not needed to particularly understand a piece of code, like in a headers. Still links are much more volatile than the codebases I work with. But I understand that may not hold in many many others setups.

And at the very least, "80-characters-per-line is a de-facto standard for viewing code" has been long wrong. As the post even mentions, 100 and 120 columns have been another popular choices and thus we don't really have any de-facto standard about them!

My opinion is that line width depends on identifier naming style.

For example Java often prefers long explicitly verbose names for class, fields, methods, variables.

Another approach is to use short names as much as possible. `mkdir` instead of `create_directory`, `i` instead of `person_index` and so on.

I think that max line length greatly depends on the chosen identifier naming style. So it makes sense to use 100 or 120 for Java and it makes sense to use 72 for Golang.

C code often use short naming style, so 72 or 80 should be fine.

And you risk a collision for global identifiers, which cannot be reorganized in C. If some library had the same thought and defined `mkdir` first, your code can't define `mkdir` even as a private symbol. So you have to prefix everything and that contributes to the identifier length. In comparison, Go has a much better (but personally not yet satisfactory) module system and can have a lower limit.

Also on age, e.g. I began to prefer grandma font size from time to time for better focus, and that changes my workspace geometry.

For mkdir all-in, meh. It’s okay for mkdirp or rimraf, cause these basically became new words. But once you add more libs or code to a project it becomes a cryptic mess of six-letter nonsense. English code reads best, Java just overdoes it by adding patterns into the mix.

C is the worst at naming length since everything is in the global namespace unless you're working on a teeny tiny project. So everything gets clunky prefixes to use as pseudo-namespaces or overly descriptive name to avoid conflicts.

Local variables sure, be short and terse. But that's common in most languages.

I doubt that rule applies to pasting URLs in comments. It's about code.