LineLength too strict for PHP8 namespaces

[rjd22]

Describe the enhancement

As of PHP8, namespaces are considered as a single token (https://wiki.php.net/rfc/namespaced_names_as_token).

Therefore it is now impossible to do:

use Name\Space
\Class;

When the namespace is too long, and exceeds the LineLength limit, PHPCS raises an error on the lign being too long.

From PHP8, the LineLength should not apply to import statements.

Code sample

# file 1
namespace A\Very\Extremely\Long\And\Ridiculous\Namespace;
class ThisIsAVeryPreciseAndSinglePurposeClassWithAVeryLongName {}

# file 2

namespace My\Other\Namespace

use A\Very\Extremely\Long\And\Ridiculous\Namespace\ThisIsAVeryPreciseAndSinglePurposeClassWithAVeryLongName;

class SimpleClass{}

To reproduce

Steps to reproduce the behavior:

Create 2 files with the above content
Run `phpcs test.php` ...

Describe the solution you'd like

I've took a stap at this previously but didn't have time to continue on it and also wanted to wait out the phpcs 4.0 release. I'm willing to do the work to fix this but would like to discuss what the most preferred way so solve this would be.

My goal to to avoid users having to add phpcs:ignore tags for long use statements and to improve the developer experience.

Additional context (optional)

• I have read the Contribution Guidelines and this is not a support question.
• I intend to create a pull request to implement this feature.

[jrfnl]

Thanks @rjd22 for reporting this and for your willingness to work on the issue.

For the record - this was previously reported in squizlabs/PHP_CodeSniffer#3606 and an earlier, related PR can be found here: #648

From PHP8, the LineLength should not apply to import statements.

I don't think that's a valid assessment of the problem.

I think the problem statement should be:

As of PHP 8.0, PHP no longer allows whitespace within namespaced names, which means that long names can not be spread out over multiple lines (which was possible prior to PHP 8.0).

As a result of this, projects which:

1. ... have (very) long namespace names and/or long class names
2. ... AND choose to use the Generic.Files.LineLength sniff
3. ... AND do not (want to) adjust the values for the $lineLimit and/or $absoluteLineLimit properties on the sniff
4. ... AND do not want to use ignore annotations for those files where this becomes a problem

... those projects now end up with "unsolvable" errors throw by PHPCS.

The above list already shows four different ways to "solve" the issue without even touching the sniff:

1. Use shorter namespace names and/or shorter class names.
2. Remove the Generic.Files.LineLength sniff from the ruleset.
3. Adjust the values for the $lineLimit and/or $absoluteLineLimit properties for the sniff via the project ruleset to values more appropriate for the project under scan.
4. Possibly use phpcs:disable .../phpcs:enable comments for the header blocks of files running into this issue.

I'm willing to do the work to fix this but would like to discuss what the most preferred way so solve this would be.

Happy to discuss this further. What other solution directions did you have in mind ?

[rjd22]

I'm working on some bigger projects that are domain driven and have a lot of modules. For organizational reasons namespaces can become quite lengthy. Combine this with very descriptive class names that describe complex processes and they will cross the line length.

Ofcourse we want to keep the line length check for all other parts of the class. So we're often left with only option 4.

It would be a real improvement to developer experience if the line length could be disabled for only the use statements so that we don't have to add these ignores manually. IDE's often automatically import the classes and hide the use statements.

What I'm looking for is a good compromise between the different ideologies. So that if someone feels that you should just reduce namespace length they can enable the check. But if someone has really big applications and feels this would reduce clarity they can disable it.

[jrfnl]

For organizational reasons namespaces can become quite lengthy. Combine this with very descriptive class names that describe complex processes and they will cross the line length.

It would be a real improvement to developer experience if the line length could be disabled for only the use statements so that we don't have to add these ignores manually.

What I'm looking for is a good compromise between the different ideologies. So that if someone feels that you should just reduce namespace length they can enable the check. But if someone has really big applications and feels this would reduce clarity they can disable it.

@rjd22 I believe I understand your intention, but I still don't agree with the focus on import use statements as that - to me - is a subset of the problem space and a subset for which there is a perfectly valid solution available: group use statements.

use A\Very\Extremely\Long\And\Ridiculous\{
    Namespace\ThisIsAVeryPreciseAndSinglePurposeClassWithAVeryLongName
};

As I stated in my previous reply, I believe the real problem is with namespaced names in the context of the PHP 8.0 change:

As of PHP 8.0, PHP no longer allows whitespace within namespaced names, which means that long names can not be spread out over multiple lines (which was possible prior to PHP 8.0).

This means that the namespaced names used in code like the below can not be split across multiple lines:

namespace A\Very\Extremely\Long\And\Ridiculous\Namespace\Name;

echo \A\Very\Different\Long\And\Ridiculous\Namespace\Name\do_something();
new namespace\ThisIsAVeryPreciseAndSinglePurposeClassWithAVeryLongName();

Different code structuring choices could be made to still comply with line length regulations, but flagging these lines with a different error code would allow projects to choose to ignore the line length issue if it is primarily caused by a very long namespaced name.

I imagine you may need to investigate the best way to determine this, but I can imagine a solution which would change the error code if the line which is too long contains a T_NAME_QUALIFIED, T_NAME_FULLY_QUALIFIED or T_NAME_RELATIVE token which is longer than the lineLimit/absoluteLineLimit.
(and yes, that would include import use statements too)

Does that make sense ? Does that help you to get started on a PR to solve this ?