Consider increasing the advised maximum column count

[christianparpart]

What's needed?

The currently advised column count is 88 (as per pyproject.toml). This looks like an already increased value from the good old 80x25 times (fun fact, back then we used to have a max column count of 78, because left and right margin columns where potentially used for ASCII line drawing, like editor border).

In today's world, 202x, most users have HD to UHD screens and a much higher terminal/editor width-and-height configuration, way beyond 80x25.

This value should certainly not go total mayhem, because a good maximum column count per coding line should still be conveniently be caught by the developer's eyes (excluding myself here).

Proposed solution

My proposition is to advise a character/column limit of 110. This value is a pure suggestion out of personal experience. I only rarely exceed the limit in cases were breaking it up would reduce readability.

This is more a decision process ticket with a tiny change to the project configuration. Future PRs might take advantage of this. :)

Use cases

Code is not always more readable if it's forcefully broken up into multiple lines. Sometimes it makes sense to have longer lines. Since the today's screen space is more than fitting, we should use it.

Alternatives and workarounds

No response

Additional context

NB: 3 years ago (2022), the Linux kernel coding guidelines also moved up from 80 to 100.

[leandro-lucarella-frequenz]

We are using black, and this is black's policy about line length:

You probably noticed the peculiar default line length. Black defaults to 88 characters per line, which happens to be 10% over 80. This number was found to produce significantly shorter files than sticking with 80 (the most popular), or even 79 (used by the standard library). In general, 90-ish seems like the wise choice.

If you’re paid by the line of code you write, you can pass --line-length with a lower number. Black will try to respect that. However, sometimes it won’t be able to without breaking other rules. In those rare cases, auto-formatted code will exceed your allotted limit.

You can also increase it, but remember that people with sight disabilities find it harder to work with line lengths exceeding 100 characters. It also adversely affects side-by-side diff review on typical screen resolutions. Long lines also make it harder to present code neatly in documentation or talk slides.

https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#line-length

This all sounds very reasonable to me, and if we are using black, I would prefer to stick with black's defaults as much as possible. It seems like most sources advice against going beyond 100 characters, so we are talking about an extra 12. I don't think that justifies diverging from the default.

Also, one of the main reasons to use black is to avoid these styling discussions, as if we change it 110, tomorrow there will be someone else asking to either increase it to 120 or to get it back to 88. If there is no clear rule that will make everyone happy, again, I would just stick to the default and keep the dictatorial spirit of the tool of ending trivial styling discussions by saying no, sorry we do it this way :D.

[llucax]

We had no more complains about this, so I'm closing this discussion.