- Issue created by @kingdutch
-
klausi โ
authored 4288ec74 on 8.3.x
fix(Namespaces): Case sensitive sorting for use statements (#3470716)
-
klausi โ
authored 4288ec74 on 8.3.x
- Status changed to Fixed
4 months ago 11:23am 1 September 2024 Automatically closed - issue fixed for 2 weeks with no activity.
- ๐ฌ๐งUnited Kingdom jonathan1055
For reference, this modification is in Coder 8.3.25 which was released on 22 Sept. However, Core 11.x is currently still running Coder 8.3.24 (as of 5 Oct).
We can re-open the Core issue #2885792: Sort use statements โ when 11.x moves onward and uses Coder 8.3.25
- ๐บ๐ธUnited States bkosborne New Jersey, USA
I'm a little confused why this was committed and pushed out as a release when it's not officially adopted as a coding standard yet? I think I just made an assumption that coder only includes things that are part of the coding standard. But I guess they can't always happen simultaneously?
- ๐บ๐ธUnited States cmlara
think I just made an assumption that coder only includes things that are part of the coding standard
Coder checks your Drupal code against coding standards and other best practices
https://www.drupal.org/project/coder โWe could maybe argue that โbest practiceโ allows this however I would expect that to be in the DrupalPractice rule set not the Drupal rule set.
But I guess they can't always happen simultaneously?
reportThe last step in the coding standard process is creating the Coder rule.
https://www.drupal.org/project/coding_standards โEven more interesting is the Coder team tried to use committing the rule as grounds to expedite the standards change https://www.drupal.org/project/coding_standards/issues/1624564#comment-1... ๐ Coding standards for "use" statements RTBC rather than removing the rule they had previously incorrectly added.
Iโm not sure where I stand on what the order should be (it is a trivial standard) however I donโt agree with this being released alongside bugfixes given the rigorous debate still ongoing.
Hopefully coder in the future will be careful about tightening rules.
As an aside it would be nice to see semver adopted with new standards and standards changes as โminorโ releases and bugfixes as patches for those who may wish to adopt standards at a set time.
- ๐ฌ๐งUnited Kingdom jonathan1055
I've been involved with Coder for nearly ten years (my first patch commit was Dec 2014) and during much of that time, from what I understand, the Coding Standards team/committee had trouble getting members and participation, and the update process had become out of date and no one was following it. So it was helpful that Coder stepped up and was pro-active in adding new sniffs and covering more standards.
But in recent years (maybe the last two or three) the Coding Standards Project โ has been revitalized, with more active members, a re-written review process on the project front page, weekly meetings on Slack and saved as issues โ , blog posts on upcoming changes for feedback, change records โ , etc. The correct order of doing things is that the standard (either new or changed) should be agreed fully within the Coding Standards team before the Coder sniff is altered or a new one written or imported.
I'm not "having a go" at any of the Coder committers, I've worked very happily with them, they're friendly helpful and a great asset, so please don't take my comments the wrong way. But I do think now is the time to try to avoid a problem like this from happening again, where the Coding Standards are having to defend themselves and the decisions retrospectively from annoyed users who feel that the process is not being followed and changes of standards just arrive without the full process being followed.
- ๐ฆ๐นAustria klausi ๐ฆ๐น Vienna
Very sorry for the disruption this caused.
The coding standards issue in question has been worked on for 12 years, I don't want to wait that long in Coder for adopting useful standards.
Now it turns out that the case-sensitivity of the standard causes pain - probably best if we open a new issue to weigh pros and cons of a revert.
In the meantime please use workarounds:
* Disable this sniff in your project
* Configure phpcbf in your Phpstorm to auto-fix the use statement ordering so that you don't have to think about it. - ๐ฌ๐งUnited Kingdom jonathan1055
Thank You Klausi for your understanding and also your commitment to getting Coder changes implemented.
For those coming here having had this problem, if you want to override the case-sensitivity setting, the the following to your project's phpcs.xml file:
<rule ref="SlevomatCodingStandard.Namespaces.AlphabeticallySortedUses"> <properties> <property name="caseSensitive" value="false"/> </properties> </rule>