Increase line length limit to 120

Looking for inspiration elsewhere. There's the PSR12 coding standard. Which says:

There MUST NOT be a hard limit on line length.

The soft limit on line length MUST be 120 characters.

Lines SHOULD NOT be longer than 80 characters; lines longer than that SHOULD be split into multiple subsequent lines of no more than 80 characters each.

There MUST NOT be trailing whitespace at the end of lines.

Blank lines MAY be added to improve readability and to indicate related blocks of code except where explicitly forbidden.

There MUST NOT be more than one statement per line.

Also worth reading are https://nickjanetakis.com/blog/80-characters-per-line-is-a-standard-wort... and https://hackaday.com/2020/06/18/ask-hackaday-are-80-characters-per-line-...

Whilst working on the inline array Array.LongLineDeclaration coding standard I did some analysis on how the numbers would be affected when the limit is increased - see #3116859-26: [meta] Fix Drupal.Array.Array.LongLineDeclaration coding standard from #26 to #32

I support the case for increasing the limit to 120 for D9 and keeping it at 120 for D10. We also have to ask why we check this just for inline arrays and for comments, but not for other code lines.

Huge plus one on this:

+1

I'm creating some JS for Olivero, and to pass linting I have to re-write

document.addEventListener('touchstart', (e) => {
  if (areAnySubNavsOpen() && !e.target.matches('.primary-nav__menu-item--has-children, .primary-nav__menu-item--has-children *')) {
    closeAllSubNav();
  }
}, { passive: true });

as

document.addEventListener(
  'touchstart',
  (e) => {
    if (
      areAnySubNavsOpen() &&
      !e.target.matches(
        '.primary-nav__menu-item--has-children, .primary-nav__menu-item--has-children *',
      )
    ) {
      closeAllSubNav();
    }
  },
  { passive: true },
);

The first example is far more readable than the second example, IMO.

In #9 the second piece of code is more readable on drupal.org, while the first piece of code is more readable in an IDE. Might be something we want to address (design-wise) if we make this change.

+1 from me on this as well, code is more art than science anyway

+1
I created #3039007: Relax the rule that arrays may not span more than 80 characters some time ago because the Content Security Policy module's admin form has a pretty deep form array, and altering the parents hierarchy of elements and retrieving values from the form state both end up crossing the 80 character limit.

+1 here too

This is linked from #1539712: [policy, no patch] Coding standards for breaking function calls and language constructs across lines, and it is very related. This change however is about not just for function calls and language constructs but for our entire code.

I think the reasons given in the IS here are mostly preference

The code gets ugly with many unnecessary line breaks.

I don't think this is an objective measurement, but I don't disagree.

The code is rewritten to use a "stupid" style to comply with the standard. Like the ternary operator is not used just because of the code line would be over 80 chars. So it is rewritten to if statement.

I disagree with this, if statements are very often a lot clearer and are a lot easier when scanning code. I think a lot of people overuse ternary operators to make their code shorter and often think that readability is more important.

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.

This is true, it sometimes make it worse to read, so this is a good argument I think.

Suggestion:
Change the standard to "around 80-100 characters" for D9.
Use "around 100-130 characters" for D10.

I disagree with this suggestion, especially because it differs between versions and because it uses around, I'd prefer to have hard requirements here, because that makes checking with phpcs possible.

When looking at #3, there is also a mention of there not being a hard limit, but in practice the phpcs prs12 implementation has a hard limit at 120 chars, and I think that's a good idea personally, this is also mentioned in #7.
I also agree with #10, the code blocks on d.o are limited to 80 chars wide now, so these will have to change as well to allow for the 40 extra chars.

I think we have to change the language on this issue to allow all code to be maximum of 120 chars.
While we can copy the wording of psr12 here, I think the soft limit will in practice be a hard limit because of phpcs.

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 #3354774: Fix the issues reported by PHPCS 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

Joomla states

There is no maximum limit for line lengths in files, however, a notional value of about 150 characters is recommended to achieve a good level of readability without horizontal scrolling

https://developer.joomla.org/coding-standards/basic-guidelines.html#:~:t....

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.

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 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".

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 it is 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.

I created a draft change record, as this is the next in the steps of remaining tasks.
I think consensus in this issue is a soft limit of 120 characters without a hard limit at all.

There is core issue about the line length in js files, #2924755: Set max line length for JavaScript code comments to 80 (rather than 100). From that I found that for js files the maximum line length checks are not run, "max-len": "off",.

I checked that with the code sample from #9. That did not result in errors about line length. Presumably, there are other config options about the formatting of if statements at work for that.

In summary,

• The proposal is for the line length of code, not comments.
• Comments will remain at 80 character length
• For core, there is no enforcement of a hard line length limit for code in any language.
• The airbnb guide states "Avoid having lines of code that are longer than 100 characters (including whitespace)"

Or, in other words, this change is documenting the current practice. And if that is correct, do we need a change record? I think not.

I think it's still good to create a change record, because even though the rule was not enforced, I would frequently push back on code > 80 wide, which now no longer should happen at all.

Ah, good point. Thank you.

OK, more investigation and there are 18 other uses of 80 in the coding standard. Those need to be checked and probably adjusted. Plus, the text in the issue summary is in the PHP section. So, this does need work to get the documentation updated for all languages.