This kind of thing is really obtuse and it drives me insane that so many people subscribe to ideas like these.
This kind of thinking is what leads to linters with completely arbitrary rules telling me how I should solve my own problem.
Me: "Hey linter, I'm going to shadow a variable name here, because that's the right thing to do in this situation, so shut up about it."
Linter, and 5 billion HN commenters: "you're shadowing a variable. Compile warning."
Me: "it's a language feature, and it's ok to use."
Linter: "you're shadowing a variable. Compile warning."
Etc.
Arbitrary rules like line width (and I assure you, those rules ARE arbitrary) help exactly 0 people per day, and cause problems for more than 0 people per day.
I PROMISE that a human brain is better at discovering general code quality problems than the best linter with the best rules, and that will be true until a time when every reasonable computer is a general purpose AI.
Yes, tell me when I have a memory leak. Use static analysis to tell me about weird issues I have difficulty seeing. I know best about line width and how to solve things in my own application better than any linter could ever hope to, because linters do not have anything approximating the intelligence of gnat, nevermind a human being.
Linters' line length rules solve a problem of useless bikeshedding and introduce consistence to the code. This already helps everyone involved in reading and writing the code.
Instead everyone just creates rules that they like, then force those rules on everyone else as a power move, then use "this is for consistency and anti-bikeshedding" as an excuse to keep their own preferences enforced on others.
And before anyone argues, I've seen it happen multiple times. I swear people become team leads solely to force their preferences on others. They certainly are fond of power trips, in my experience.
I use a linter, it warns about long lines (adjusted to 100), so I reformat or split them and the code seems more readable. Also, it has consistent formatting (other rules), though I occasionally mark some lines to be ignored.
I'd say it helps me, which is >0 people. You don't have to follow norms and/or best practices, but some find it useful.
I have no idea why you think I am arguing for stuffing arbitrary line lengths in code. I was arguing for the exact opposite, that line length limits are rarely beneficial.
But if these cases are exceptional then you can use pragma to suppress those warnings for that particular block of code. If they are not exceptional perhaps you shouldn't have enable the warning/linter check for that warning.
But honestly I can't think a good reason for shadowing variables and would appreciate an example
I can't agree with that. When you've got class names like AbstractSingletonProxyFactoryBean and similar naming conventions for variables, 80 characters just isn't adequate a lot of the time.
Really, is there any writing that doesn't seem to apply?
Also, lines ending on column 100 are not necessarily 100 characters long. There could be indentation on that line and on the next.
Vertical alignment has meaning in code whereas it ususally doesn't have meaning in natural language text.
So if you insert line breaks into code purely to follow some arbitrary rule, you are misleading readers into looking for meaning where there is none.
Recipes often do two columns of some things. Math jargon is all about repetition. Narrative, explanation, exposition.
Don't get me wrong, I am inclined to agree with you. But we don't have a ton of empirical evidence on our side.
Neither does the other side, unless you accept the premise that reading natural language text is similar enough to reading heavily indented code where that indentation has meaning. I don't accept that at all.
The studies that were done on natural language text assume that line length is equal to the column where the line ends (i.e all lines begin on the left edge). That's not usually the case for indented code.
If reading long lines takes more effort because your eyes have to travel further to find the next line, then the amount of indentation the next line has matters are great deal.
And looking at this before I hit go. You seem to ultimate be agreeing. Taking opening indentation into consideration concedes that long lines are bad. You just give some room for margins. And are ok with all of the mental stacking that the indentation implies.
In math-heavy stuff, lines tend to be longer. You are usually trying to convert one line of math into one line of code. I myself shoot for 160 character columns.
See, e.g. [1].
When long lines improve readability/ clarity you should have the ability to use them.
As I said above, if your code is loaded down with tons of long lines of code, it's likely a symptom that something else is wrong. If code is difficult to read, it's bad code.
Isn't perceived difficulty of reading code correlated with how familiar one is with the language it's written in? For example, code may be harder to read for someone who lacks experience or is new to the language, but it's not difficult for someone who is experienced and is familiar with the language.
No, it doesn't, especially for code that isn't written in a very basic simplistic imperative style. Expressions have no natural size limits (and statements, in languages that even have them, can generally each contain one or more expressions.)
Languages tend to develop conventional line width limits and conventions for where to prefer to break within expressions to achieve them, but there is no natural length limit to the length of a single statement.
There is some truth to this, but it's largely irrelevant. When text is laid out for books, it's based on a fixed width and each sentence follows the next. Code isn't laid out that way, with code, each statement starts on a new line which naturally limits line width.
Good programmers gravitate towards shorter lines of code by nature. If your average line of code is wider than 80 characters, it's likely you have some other, bigger coding style problems which need to be addressed.
But having the option to use longer lines when it makes the code more readable is also valuable. Putting a fairly short, arbitrary limits on line length just makes other parts of coding less pleasant, variable names in particular suffer quickly when you can't make comparisons on a single line.
Where I work, we wrap lines at 120 characters but the overwhelming majority of the code is less than 80 characters wide. Longer lines are reserved for if statements with multiple conditions or ternary assignments.