Increase line length limit to 120

I also want to join the +1 force here, totally in support for PSR-12. The 80 char limit is harmful nowadays.

When I write my code, I always try to write it readable in my IDE. It is an instinctive, natural behavior to set line breaks to support your own thinking process. And then I run phpcs and 80% of the reports I'm getting are line length issues, and a lot of those are in between 80 and 120 chars. This is frustrating and feels like mutilating your own code, making it much harder to read again, just to follow ancient coding standards.

+1 here too

I see absolutely no reason for a 40, 80 or 120 characters hard limit.
If a visually impaired developer chooses to develop on a 14" laptop using a huge font-size, this fine human will just have to make his editor wrap the code.

Paqualle pointed to this response from Linus:

So the fact is, many of us have long long since skipped the whole "80-column terminal" model, for the same reason that we have many more lines than 25 lines visible at a time.

And honestly, I don't want to see patches that make the kernel reading experience worse for me and likely for the vast majority of people,
based on the argument that some odd people have small terminal windows.

If you or Christoph have 80 character lines, you'll get possibly ugly wrapped output. Tough. That's _your_ choice. Your hardware limitations
shouldn't be a pain for the rest of us.

Longer lines are fundamentally useful. My monitor is not only a lot wider than it is tall, my fonts are universally narrower than they are
tall. Long lines are natural.
[...]

So no. I do not care about somebody with a 80x25 terminal window getting line wrapping.

For exactly the same reason I find it completely irrelevant if somebody says that their kernel compile takes 10 hours because they are doing kernel development on a Raspberry PI with 4GB of RAM.

People with restrictive hardware shouldn't make it more inconvenient for people who have better resources. Yes, we'll accommodate things to within reasonable limits. But no, 80-column terminals in 2020 isn't "reasonable" any more as far as I'm concerned. People commonly used
132-column terminals even back in the 80's, for chrissake, don't try to make 80 columns some immovable standard.

If you choose to use a 80-column terminal, you can live with the line wrapping. It's just that simple.

So I'm +1 for no hard limits and +1 for no soft limits. PHPCS unable to do soft limits? Not our problem.

Just ditch the ancient character limits.

I'm sure this will lead to happier developers and more legible code for +97% of the developers.

+1 for increasing it to 120 lines, or even no limits. Core contributors, contrib module maintainers, and README.md editors spend too much time on this tedious task, which is essentially a relic of the past.

Case in point is 📌 Fix the issues reported by PHPCS Fixed from today:

The indentation typos are clear but, to tell you frankly, I probably can't be forced to change the 80-line. I consider it one of the stupidest assumptions in 2023 and fight it tooth and nail in other languages and IDEs as well. People don't use 80-line VGA terminals any more, neither do I, there's absolutely no sense in this requirement, quite the opposite, it makes contemporary programming a pain.

I'm a very strong proponent of legible, well organized code but this just flies in the face of all that.

The 5 offending lines, which would not have been an issue with max. 120 lines limit, or none:

3 | WARNING | Line exceeds 80 characters; contains 85 characters
7 | WARNING | Line exceeds 80 characters; contains 90 characters
8 | WARNING | Line exceeds 80 characters; contains 91 characters
11 | WARNING | Line exceeds 80 characters; contains 97 characters
12 | WARNING | Line exceeds 80 characters; contains 105 characters

There does not seem to be much opposition to increasing the line length. Who needs to be involved in this issue thread to make a change to the coding standards?

+1 for increasing to 120 lines. The core source does not appear to be hindered by this excessively strict rule.

Echo above from @ChrisSnyder question: What needs to happen to get movement on this issue?

What needs to happen to get movement on this issue?

If you are on Drupal Slack you could raise it in the #coding-standards channel
https://app.slack.com/client/T06GX3JTS/C02LJCF78E8

+1 for this issue.

Laravel follows PSR-2 and that states https://www.php-fig.org/psr/psr-2/

There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.

https://laravel-news.com/php-codesniffer-with-laravel
Even WordPress has more room there.

Lines should usually be no longer than 80 characters, and should not exceed 100 (counting tabs as 4 spaces). This is a “soft” rule, but long lines generally indicate unreadable or disorganized code.

https://developer.wordpress.org/coding-standards/wordpress-coding-standa...

Let's update this 10 year old issue.
https://www.drupal.org/project/drupal/issues/935284 →

Updated issue summary with the current consensus of the new line length.
Also added info on how to change the allowed length in a project's phpcs.xml(.dist) file if you want to start using this anyway.

Added second example for array-wrapping line length.

+1

I'm leaning towards a -1 on this.

> - The code comments are shortened just to comply with the standard. I am sure everyone does it if the comment is between 81-85 chars.

Wide text is harder to read. This is the reason newspapers are printed in columns and well-designed web pages don't let their text go to the full width of the window.

Coding standards are adding more line breaks generally -- in function declarations, function calls, and so on. These make code more readable, and produce cleaner diffs too.

Wide text is harder to read.

I would like to see a code comment example where this is true.

This is the reason newspapers are printed in columns and well-designed web pages don't let their text go to the full width of the window.

Agree that for reading stories and normal text, 80 should be the max (I actually prefer less). However reading normal text is very different than reading code.

Wide text is harder to read. This is the reason newspapers are printed in columns and well-designed web pages don't let their text go to the full width of the window.

Agree that for reading stories and normal text, 80 should be the max (I actually prefer less). However reading normal text is very different than reading code.

I'm with @mherchel here. Stories usually don't have a line break after each sentence. But code usually has a linebreak after each statement anyway, making it very different to read than editorial text.

I'm thinking of the large paragraphs of docblocks we have in our codebase. E.g. -- and this is only an average sized one -- https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

This is why we should adopt something similar to #3. Where we recommend 80 characters or less but if there good reasons you can be longer. The whole hard limit at 80 characters sometimes forces the one liner for methods to become really bad documentation. In those instances we have our priorities wrong. Adhering to the line limit instead of correctness is the wrong way around.

The Coding Standards Committee has developed a custom issue template → to assist in managing issues efficiently. We have already found that it's use is helping. For issues created before the template was in use I am adding the new template to the Issue Summary and asking everyone here to help convert to it..

Thank you for your help!

Joachim is absolutely correct regarding docblocks (#29). They are easier to read when only 80 chars wide. "Make your docblocks easier to read by aiming for a width of 80 chars" is a clearly a sensible recommendation.

But, using the exact same example, everyone is way happier with the 96 char line at
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...
than with some chopped up, harder to read, 80 char monstrosity. And also already allowed per "Control structure conditions may exceed 80 characters, if they are simple to read and understand". But you

The same goes for mherchels 130 char line in #9. Way better than any chopped up 80 or 120 char monstrosity.
Also already allowed per "Control structure conditions may exceed 80 characters, if they are simple to read and understand".

Let's be pragmatic thinkers and doers and extend "may exceed 80 characters, if they are simple to read and understand" to everything.

No hard or soft limits. Just (modern) common sense recommendations on legibility.

Reinstating the full 9 step "remaining tasks", as this serves as the checklist for the process.