The maximum width of a line from the first printing character to the last should be limited to about 40 characters.
The absolute line length should not be subject to a hard limit.
This is because code indents:
------
-----
-----
------
------
------
What I don't want to be obnoxiously long is any of the ----- content itself, regardless of how much or how little indentation is in front of it.
I don't like ridiculous nesting, but imposing some hard limit like 80 columns or 100 is counterproductive; let that naturally limit itself.
When confronted with these limits, programmers do ugly things, like start using shorter and shorter lines at deeper nesting levels, those lines being awkwardly split to fit:
fun(arg, // 80th column here
arg, //
term + //
term + //
term); //
Please, just go over 80 and write fun(arg, arg, term + term + term)!
The counterargument is that if you ever have to produce hard copy, it's good if the code sticks to reasonable number of columns. I think we are past the era where people bring hardcopies of code to code reviews, though. We also care about code histories a lot more; printing out a program on paper is no longer considered a viable way to preserve it for future generations, since it loses the change history.
Forcing people to split their function into subfunctions to reduce nesting usually works well. Occasionally I'm reluctant to do so, but whenever I do, the code seems to get better. Obviously don't take it to the extreme but if you're 5 levels deep already there's probably a nicer way to write that.
Helper functions that are called only once can easily make the logic harder to read than the original function. Now you have to jump around through detours to recover the linear flow. If the functions aren't inlined, it can slow things down for the machine too.
The absolute line length should not be subject to a hard limit.
This is because code indents:
What I don't want to be obnoxiously long is any of the ----- content itself, regardless of how much or how little indentation is in front of it.I don't like ridiculous nesting, but imposing some hard limit like 80 columns or 100 is counterproductive; let that naturally limit itself.
When confronted with these limits, programmers do ugly things, like start using shorter and shorter lines at deeper nesting levels, those lines being awkwardly split to fit:
Please, just go over 80 and write fun(arg, arg, term + term + term)!The counterargument is that if you ever have to produce hard copy, it's good if the code sticks to reasonable number of columns. I think we are past the era where people bring hardcopies of code to code reviews, though. We also care about code histories a lot more; printing out a program on paper is no longer considered a viable way to preserve it for future generations, since it loses the change history.