But no, 80-column terminals in 2020 isn't “reasonable” any more

I have a fairly simple solution for the scenario you’ve presented. grep, and return some context (maybe +5) and then grep on that again with the argument you’re looking for (give a negative context this time so you get the entire function call)

That being said, as unlikely that scenario is, having it all in 1 line does not work either. The problem is that its very likely/possible that the true argument will be passed in in the form of a variable. So you’re back to needing something that is more code aware anyways.

I think this is a subject most editors fail to address.

A single line of code should be written to file as a single line - no matter how long. However, the editor you are using should be able to gracefully word wrap it depending on your settings.

Most editors word wrap based on window size or some other hard setting. They should be able to wrap gracefully at a logical point in the code e.g. at a comparison operator or a dot in a function chain. Wrapped lines could be tabbed or visually flagged to let you know.

In other words there should not be am ideal line length for code, but instead editors should be able to adapt to make life easier for developers.

Look at word processor documents, imagine how much of a nightmare it would be if such documents had a hard limit of characters per line.

> The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left.

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.

I've also been buying a larger monitor every few years, as the prices drop.

But I hated the 42" 4K I tried and returned it. The problem was the edges are just too far away. If I use them I end up with the same kind of neck strain I would get with a multi-monitor setup. So I only used kind of the middle section of the screen anyway. And at 42" 4K the physical pixels are just too big - everything is fuzzy.

32" 4K is the sweet spot for me. Maybe when there's a reasonably priced 42" 8K curved display I'll give it a go.

In practice you get problems, because of the line length rule.

I.e. if your editor is configured with four-space tabs and a line with one leading tab shows up in your editor having 79 characters, it will show up as 83 characters for others assuming the normal 8-space tabs thus breaking the line length rule.

Not to mention that coding style may require that function calls broken to 2 lines must have the arguments aligned at the opening parenthesis.

For example, breaking up foobarbaz(1, 2); into two lines would require having the second line start with 2); which would no longer look correct with 4-space tabs.