-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include Generic.Arrays.DisallowLongArraySyntax #34
Conversation
I'm not sure how we feel about depending on other projects, but I'm currently using the following rules locally too:
These ensure that:
The MediaWiki Sniff is licensed under GPLv2: |
Perhaps, if we think the MediaWiki sniff is generally useful, we should (with their consent) contribute it upstream, renamed to Generic.Arrays.... ? |
Hi, while there are some good standards out there (say Slevomat Mammoth, specially and also some nice picks from others like Drupal, Mediawiki...) I'm in favour of using exclusively the Sniffs that come with phpcs (Generic, Pear, Squiz, PSRX...) and our very own ones (of course). The only dependency that we currently have is the PHPCompatibility one and, to be honest, I'm not sure how useful it is because they haven't released since 2019 (and their unreleased master branch has A LOT of improvements, in fact we use it always as a regular issue in the PHP X.Y epics). Also, in other standards, they can change dependencies suddenly, like having a Mediawiki XXX file or checkout... and other things... so can introduce unexpected behaviours. We already do that for some of our Sniffs (instrospect version.php, load components.json, soon load also apis.json...) So I'd say, let's copy (adopt, respecting copyrights) but make them ours. Also, triple check that none of the bundled standards have it. Sometimes I've found some good gems, specially within Squiz. My very basic opinion. Ciao :-) |
I agree with Eloy, but with the addition that, if a third-part ruleset has a useful potentially-generic sniff, then we should try got get that sniff moved to the generic ruleset. (In our copious free time, of course, but while that may take more work in the short term, it probably saves in maintenance in the long term.) |
I also agree with Tim, to propose something (clearly logic and global) to find its place into the upstream standards makes perfect sense. |
While I personally like this (switch to short syntax), here there are a couple of reflexions:
Thoughts? Can be a nice Xmas present for everybody out there (for the good and the bad, heh). Ciao :-) |
Let's do it. |
It seems that it will be a NY present, instead of a Xmas one, but yay in any case! |
Hi, with https://tracker.moodle.org/browse/MDLSITE-4776 decided and documented... it's time to decide about this one. Only point open to discussion is if we should introduce this as a warning, or go straight to be an error (current implementation). For some reason, I prefer the Thoughts? |
For all new code, it's definitely an error. For existing code, it's technically a warning. Rather than try to differentiate, it's probably best to have it set as an error in all cases. Anyone who is not being strict about following moodle-cs in their plugins may see some additional "error" messages. I would hope that anyone that is strict about following moodle-cs is willing to update existing code to align with these changes. Summary: +1 error |
The moodle-cs ruleset will start reporting problems soon, see moodlehq/moodle-cs#34.
Soon it will be a Valentine's Day present 😉 |
The question is... of which year? 😛 Seriously, I've asked the team for opinions about to:
We have followed that approach in the past (for example the "and/or" one was raised few days ago @ #53) and I think it has worked ok enough. Ciao :-) |
5b1b0be
to
b6dde49
Compare
Codecov Report
@@ Coverage Diff @@
## main #34 +/- ##
=========================================
Coverage 95.53% 95.53%
Complexity 440 440
=========================================
Files 19 19
Lines 1165 1165
=========================================
Hits 1113 1113
Misses 52 52 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
I've rebased your branch on top of current So the only remaining point is if we apply for this over 1 year or no: diff --git a/moodle/ruleset.xml b/moodle/ruleset.xml
index e23657c..ac4628d 100644
--- a/moodle/ruleset.xml
+++ b/moodle/ruleset.xml
@@ -9,7 +9,9 @@
<arg name="extensions" value="php" />
<arg name="encoding" value="utf-8" />
- <rule ref="Generic.Arrays.DisallowLongArraySyntax"/>
+ <rule ref="Generic.Arrays.DisallowLongArraySyntax">
+ <type>warning</type>
+ </rule>
<rule ref="Generic.Classes.DuplicateClassName"/>
<rule ref="Generic.Classes.OpeningBraceSameLine"/> (note that the tests don't need to be amended because they don't use the ruleset.xml file, so they continue being errors there) From the team, I've got a couple of 👍 towards going the warning => error way. And, also, people can always go to use the new, stricter, standard if wanted to (see #57). Ciao :-) |
Ok, so the plan is:
On it right now (towards a release)... ciao :-) |
- as warning in the moodle standard. - as error in the moodle-extra standard. - to become error in both standards in 1y (moodlehq#58)
b6dde49
to
37033b0
Compare
Hi, I've updated your branch/commit with the details commented above (warning for Tested locally, it works ok:
Ciao :-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good for both Andrew and me, hence, approving.
Merged, will be making a release with this and the new Moodle-extra standard in 1-2h… Thanks all, ciao :) |
Disallow the long array syntax
array()
, preferring the short array syntax ([]
) instead.