> 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

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