4 ms·

Linus is making the typical bad faith argument that people use 80 char limit because of hardware limitations. No one has ever advocated 80 because of hardware

Linus is making the typical bad faith argument that people use 80 char limit because of hardware limitations. No one has ever advocated 80 because of hardware limits. Hardware has progressed but our eyes haven't. In prose, shorter lines help because you can easily go to the next line. For programming, shorter lines help because you can navigate your function better because most of what you're tracking is in a smaller area. With long lines you have to move your eyes more. Shorter lines also force you to write one param per line when calling a function. No one is saying you need to mk yr vrbls shorter.

emsy 5y ago
Nesting exists, and 80 is an arbitrary number.
- xdennis 5y ago
  Every number is arbitrary. 80 is often used simply because it's in the right ballpark and already used by many who agree on short lines. People who like long lines have no main limit they agree on and if a line limit does exist, it often varies by project... making it even more arbitrary.
  - danachow 5y ago
    The main argument is that it’s not in the right ballpark though - which has no universal correct answer. However at this point 80 is not arbitrary - It’s primarily used as a default because of ancient history when 4k let alone 640k was enough for everybody. A time when the expense of expanding a meager terminal buffer 50% was hundreds of dollars - and this goes back to ancient history of 80 column punchcards.
- numlock86 5y ago
  Doesn't Linus also regularly argue that you shouldn't nest deeper than like 3 or 4 levels?
  - iso1210 5y ago
    class X { function Y { for (i < 20) { if (array[i] == 17) { // just 64 characters left now
kyralis 5y ago
> Shorter lines also force you to write one param per line when calling a function. And this is unconditionally good why? Linus isn't wrong when he describes lines as a natural unit, already operated on by our tools and our brains. Having to stitch multiple lines together has its own mental cost. Is a longer line always better? Definitely not. There are absolutely cases where an expression split over multiple lines and well-indented can make code much clearer. There are also cases of the inverse, where you have to take a single atom that was split across multiple lines and re-integrate it while reading. (The patch that Linus is referring to here has some of these.) Line length should be driven by some combination of total character width and expression cohesion. A single line can be overly complex even far below an 80 character limit, and a single line well above that limit can still be easy to read. Prose, and therefore comments, have different reading patterns and therefore different motivations for line length. You want to limit comments and documentation to 80 characters? Fine. Code? That's valuing one metric over another, or simply hoping that strongly clamping one metric is going to also improve another.
rendall 5y ago
> Linus is making the typical bad faith argument that people use 80 char limit because of hardware limitations. Disagreement does not mean "bad faith". The character limit is 80 because of hardware. The argument for using 80 characters is not "use short lines because it's easier to read". It's not "use 85 characters if it increases readability and understanding". It's "80 characters is a hard limit and if you go over we're gonna wrap or truncate" Yes. It is 80 and not another number only because of hardware and history. It has never been about readability.
- layer8 5y ago
  Arguably, the hardware was designed to support an adequate and sufficient line length.
  - deleted 5y ago
    [deleted]
kstenerud 5y ago
I used to be an 80 char zealot, but since working in 100 and 120 char codebases, I've seen the light. Such line lengths make it MUCH easier to scan the code because we are able to scan that much without moving our eyes around a lot, and now it's not so cramped. One param per line of a function call is bad for readability (unless there are more than four params).
- orwin 5y ago
  100 is my sweet spot, unless i do Java/groovy and in this case i'd rather have 120. I still like 80 char comments/docstrings though.
waynecochran 5y ago
Also you have to view code in multiple contexts and sticking to 80 characters per line allows it it be viewable in more places. For example, I like to look at the diffs in github and it is more flexible to read in a web browser if kept to 80 chars.
marcus_holmes 5y ago
This reminds me of the thing with musical albums. Albums are the length that they are because of the technical constraints of the medium: you can only fit so many tracks on a vinyl disk. However, this constraint has been adopted by musicians as a creative constraint - an album is a "feels right" amount of music for an artist to produce. You can tell a story in an album, fit a narrative arc in that much space. But, y'know, sometimes you need a double album to tell the story properly. Some stories need more room. I like 80 lines as a guideline. It feels about right, and fits my eyeballs. But I'm not going to let that stop me if I need more space. Some code demands more space.

emsy 5y ago

Nesting exists, and 80 is an arbitrary number.

xdennis 5y ago
Every number is arbitrary. 80 is often used simply because it's in the right ballpark and already used by many who agree on short lines. People who like long lines have no main limit they agree on and if a line limit does exist, it often varies by project... making it even more arbitrary.
- danachow 5y ago
  The main argument is that it’s not in the right ballpark though - which has no universal correct answer. However at this point 80 is not arbitrary - It’s primarily used as a default because of ancient history when 4k let alone 640k was enough for everybody. A time when the expense of expanding a meager terminal buffer 50% was hundreds of dollars - and this goes back to ancient history of 80 column punchcards.
numlock86 5y ago
Doesn't Linus also regularly argue that you shouldn't nest deeper than like 3 or 4 levels?
- iso1210 5y ago
  class X { function Y { for (i < 20) { if (array[i] == 17) { // just 64 characters left now

kyralis 5y ago

> Shorter lines also force you to write one param per line when calling a function. And this is unconditionally good why? Linus isn't wrong when he describes lines as a natural unit, already operated on by our tools and our brains. Having to stitch multiple lines together has its own mental cost. Is a longer line always better? Definitely not. There are absolutely cases where an expression split over multiple lines and well-indented can make code much clearer. There are also cases of the inverse, where you have to take a single atom that was split across multiple lines and re-integrate it while reading. (The patch that Linus is referring to here has some of these.) Line length should be driven by some combination of total character width and expression cohesion. A single line can be overly complex even far below an 80 character limit, and a single line well above that limit can still be easy to read. Prose, and therefore comments, have different reading patterns and therefore different motivations for line length. You want to limit comments and documentation to 80 characters? Fine. Code? That's valuing one metric over another, or simply hoping that strongly clamping one metric is going to also improve another.

rendall 5y ago

> Linus is making the typical bad faith argument that people use 80 char limit because of hardware limitations. Disagreement does not mean "bad faith". The character limit is 80 because of hardware. The argument for using 80 characters is not "use short lines because it's easier to read". It's not "use 85 characters if it increases readability and understanding". It's "80 characters is a hard limit and if you go over we're gonna wrap or truncate" Yes. It is 80 and not another number only because of hardware and history. It has never been about readability.

layer8 5y ago
Arguably, the hardware was designed to support an adequate and sufficient line length.
- deleted 5y ago
  [deleted]

kstenerud 5y ago

I used to be an 80 char zealot, but since working in 100 and 120 char codebases, I've seen the light. Such line lengths make it MUCH easier to scan the code because we are able to scan that much without moving our eyes around a lot, and now it's not so cramped. One param per line of a function call is bad for readability (unless there are more than four params).

orwin 5y ago
100 is my sweet spot, unless i do Java/groovy and in this case i'd rather have 120. I still like 80 char comments/docstrings though.

waynecochran 5y ago

Also you have to view code in multiple contexts and sticking to 80 characters per line allows it it be viewable in more places. For example, I like to look at the diffs in github and it is more flexible to read in a web browser if kept to 80 chars.

marcus_holmes 5y ago

This reminds me of the thing with musical albums. Albums are the length that they are because of the technical constraints of the medium: you can only fit so many tracks on a vinyl disk. However, this constraint has been adopted by musicians as a creative constraint - an album is a "feels right" amount of music for an artist to produce. You can tell a story in an album, fit a narrative arc in that much space. But, y'know, sometimes you need a double album to tell the story properly. Some stories need more room. I like 80 lines as a guideline. It feels about right, and fits my eyeballs. But I'm not going to let that stop me if I need more space. Some code demands more space.