That email sure seems to be formatted for 80 columns
But no, 80-column terminals in 2020 isn't “reasonable” any more
241–250 of 330 posts
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#242I 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 o…
This would make debugging hard, as debuggers are very much line number based. Step commands move one line at a time, breakpoints are for specific lines, and stack traces from exceptions include line numbers but not character offsets.
That’s why for function calls passing multiple arguments where each argument may be non trivial, it’s a good idea to put each argument on its own line.
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#243Earlier quoted context omitted.
How can you make a linter for this?
Annotate the long line to ignore that particular linter rule. This makes it clear that it's not because the coder was lazy, ignorant, etc.
Wouldn’t that make the code less readable?
I think the point is that if 98% of your code fit under 110 chars when you weren’t using a linter, then maybe you don’t need a linter checking line length.
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#244I 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 o…
This would make debugging hard, as debuggers are very much line number based. Step commands move one line at a time, breakpoints are for specific lines, and stack traces from exceptions include line numbers but not character offsets. That’s why for function calls passing multiple arguments where each argument may be non trivial, it’s a good idea to put each argument on its own line.
Not always. I can set the breakpoint in jetbrains rider to a function in a multi function line. And Java stacktraces certainly contain character offsets.
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#245Earlier quoted context omitted.
I would gladly pay twice the price for a 4k 4:3 or 3:2 monitor. Even on wide displays, I rarely split top-to-bottom more than once. More vertical space would mean a lot more usable screen estate for me.
So just turn a 16:(9/10) monitor sideways. Plenty of vertical space.
Two of them next to eachother makes for 16:18 which is my kind of screen!
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#246Earlier quoted context omitted.
> 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 wid…
> " 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. " 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.
To be fair though, if you have class names like AbstractSingletonProxyFactoryBean, then terminal width is the LEAST of your problems.
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#247I 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 o…
Now that you’ve said it you have to make it happen!
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#248Jesus, what a bullshit. It's not about screen size, it's about reading experience. If you think that longer lines making something easier to read - try to read non-trivial book with 100 characters width.
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#249Earlier quoted context omitted.
No text editor that I know of intelligently word wraps code. Vim doesn't and Emacs doesn't either.
When I hear the word intelligently used in the context of something a computer should do I start to think that perhaps the reason it doesn't do it yet because our expectations are too wide and fickle for it to work as yet. So perhaps this is the test of AI, when it formats my code the way I want it all the time without making a mistake.
I think it’s pretty simple. Word wrap the way a N-character wide linter would
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#250The 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. Take it from the world of books: This study may be helpful: > This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 c…
Yeah, bad tools shouldn't justify bad decisions. Build better tools god damn it.