Skip to content
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

Update PHPCS default rule set #161

Merged
merged 10 commits into from
Jul 29, 2018
Merged

Conversation

NicktheGeek
Copy link

The .phpcs.xml.dist rule file is detected and implemented automatically, reducing complexity for running phpcs.

The updated rules account for new wpcs sniff properties including the ability to check global prefix and i18n implementation with the correct text domain when specified.

The values have been left blank so the sniffs are generic, but the rules are in place to make it easier to get started by scaffold.

This is tangentially related to #109

This is also loosely related to #63 as updating composer scaffolds could work with this change.

@GaryJones may be able to provide additional feedback on this file change.

The .phpcs.xml.dist rule file is detected and implemented automatically, reducing complexity for running phpcs.

The updated rules account for new wpcs sniff properties including the ability to check global prefix and i18n implementation with the correct text domain when specified.

The values have been left blank so the sniffs are generic, but the rules are in place to make it easier to get started by scaffold.
@schlessera
Copy link
Member

Yes, I would indeed love feedback from @GaryJones and @jrfnl to know whether this would be a good default starting point for new plugins.

@schlessera
Copy link
Member

@NicktheGeek For the blanks, it would be helpful to add comments so that developers immediately know where to turn the dials.

@NicktheGeek
Copy link
Author

@schlessera good idea.

@NicktheGeek
Copy link
Author

@schlessera added the comments.

<arg name="basepath" value="."/><!-- Strip the file paths down to the relevant bit -->
<arg name="colors" />
<arg name="extensions" value="php"/>
<arg name="report" value="full"/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove the reports args - the default is a full report anyway, and any different reports should be decided upon at runtime.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI: I totally agree with @GaryJones' advice about the report.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heh - the advice is what I took from Juliette!

@@ -0,0 +1,44 @@
<?xml version="1.0"?>
<ruleset name="WordPress Coding Standards for Plugins">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This naming is a bit misleading - perhaps `"WordPress Coding Standards for this plugin"? is better, and less implies that there's a WPCS specifically for Plugins?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pulling this name from the current version, but I am good to do this naming change.

Copy link
Contributor

@jrfnl jrfnl Jul 20, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May I suggest "WPCS based custom ruleset for plugins" or "WordPress Coding Standards based custom ruleset for your plugin/for plugin xyz" ?

Makes it very clear that this is a custom ruleset and not a standard. There is a significant difference between those two and naming this right will help people find the right information if they would search for more info.

To explain the difference:

  • A standard can add new sniffs, can be installed and referenced by name.
  • A custom ruleset uses existing standards and sniffs and may add configuration for these.

<arg value="sp"/> <!-- Show sniff and progress -->
<arg name="basepath" value="."/><!-- Strip the file paths down to the relevant bit -->
<arg name="colors" />
<arg name="extensions" value="php"/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another potentially useful arg is <arg name="parallel" value="8"/> - the number can vary, but 8 is a nice starting point.

Copy link
Contributor

@jrfnl jrfnl Jul 20, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Comment to add along-side it: <!-- Enables parallel processing when available for faster results. -->

<!-- How to scan -->
<arg value="sp"/> <!-- Show sniff and progress -->
<arg name="basepath" value="."/><!-- Strip the file paths down to the relevant bit -->
<arg name="colors" />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove the space before the slash.


<!-- How to scan -->
<arg value="sp"/> <!-- Show sniff and progress -->
<arg name="basepath" value="."/><!-- Strip the file paths down to the relevant bit -->
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know @jrfnl favours ./ here rather than ..

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either is fine as long as the [.]phpcs.xml.dist file is located in the project root.


<!-- Rules: Check PHP version compatibility -->
<config name="testVersion" value="5.3-"/>
<rule ref="PHPCompatibility"/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is a WordPress plugin/theme, then it can reference the PHPCompatibilityWP ruleset instead - would need the composer.json template updated as well to pull that package in.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since that is outstanding, should this remain as is and implement a change for it with #63?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would most definitely recommend changing this already to use the PHPCompatibilityWP standard instead as it will prevent false positives for things WP back-fills/poly-fills.

<rule ref="PHPCompatibility"/>

<!-- Rules: WordPress Coding Standards -->
<config name="minimum_supported_wp_version" value="3.3"/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems particularly low. I personally use current - 2 versions (so, 4.7 right now), and WPCS default is current - 3 versions (so, 4.6 for WPCS 1.0.0).

<!-- Rules: WordPress Coding Standards -->
<config name="minimum_supported_wp_version" value="3.3"/>
<rule ref="WordPress">
<exclude name="WordPress.VIP"/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be worth waiting until WPCS 1.0.0 drops, which already removes WordPress-VIP from the WordPress ruleset.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will work either way, even if the WPCS VIP deprecation would not make it into 1.0.0, so I'd leave it for now.

<rule ref="WordPress.NamingConventions.PrefixAllGlobals">
<properties>
<!-- Value: provide the function, class, and variable prefixes used. Separate multiple prefixes with a comma. -->
<property name="prefixes" type="array" value=""/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jrfnl may know better, but having a my-plugin placeholder here may better point folks towards changing it to something useful when it gives some warnings on the first run, rather than an empty value which may either blow things up, or not show any related violations (and therefore not drawing attention to changing it) at all.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

having a my-plugin placeholder here may better point folks towards changing it to something useful when it gives some warnings on the first run

I concur with @GaryJones, please do add a placeholder to give people incentive to change it.

may either blow things up, or not show any related violations

An empty value won't blow things up, but will basically disable the sniff.

<rule ref="WordPress.WP.I18n">
<properties>
<!-- Value: provide the text domain used. -->
<property name="text_domain" type="array" value=""/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think WPCS 1.0.0 now supports a better way of adding in array properties - individual entries, instead of a comma-separated value.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not WPCS, but PHPCS 3.3.0+. So if you would want to use the new array format, you would need to make sure that people are aware that they will need a very recent PHPCS version.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jrfnl will the current CSV method work with PHPCS 3.3.0+? If so it seams like it might be better to wait before implementing that even by reference.

@GaryJones
Copy link
Contributor

Rushing the review, and @jrfnl can fill in some blanks (or I can another day), but overall +1 for the PR to make it a much nicer starting point to implementing WPCS.

Thanks @NicktheGeek!

@NicktheGeek
Copy link
Author

thanks you @GaryJones after you helped me get this on GFWA I've used it on several projects and I can't tell you the number of times it has found a minor typo in the text domain and saved me so much headache down the road. That one feature is worth the price of admission.

Nick Croft added 2 commits July 20, 2018 10:16
change the the ruleset name and add a comment explaining parellel processing.
@NicktheGeek
Copy link
Author

@jrfnl Thanks! I've added the changes you recommended.

@schlessera this may need some additional feedback from @jrfnl or @GaryJones but so far I've implemented almost everything suggested. There are a couple of comments regarding WPCS 1.0.0 but IMO we are better if this is implemented now and an issue created to update when 1.0.0 comes out with additional improvements. I'm good either way though pending release timeline for WP CLI 2.0 and WPCS 1.0.0.

Copy link
Contributor

@jrfnl jrfnl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@schlessera Thanks for the ping. @NicktheGeek I've left some comments inline.

@jrfnl will the current CSV method work with PHPCS 3.3.0+? If so it seams like it might be better to wait before implementing that even by reference.

Yes, the current comma-delimited string format will still work, but it will be removed in PHPCS 4.0.

For more information about this change and the new format - much more readable! -, see the PHPCS 3.3.0 release notes: https://github.com/squizlabs/PHP_CodeSniffer/releases/tag/3.3.0


<!-- What to scan -->
<file>.</file>
<exclude-pattern>vendor/</exclude-pattern>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Be aware that exclude-pattern values are interpreted as regular expressions, so this snippet would exclude every directory which included the string vendor/, i.e. /some-other-vendor/ would also be excluded.

While this may be something which will rarely cause issues, you can stabilize this to just the Composer vendor directory by using something along the lines of ^/vendor/* or the slightly more generic ./vendor/

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For more information about how the exclude-patterns are interpreted, see: https://github.com/squizlabs/PHP_CodeSniffer/wiki/Advanced-Usage#ignoring-files-and-folders

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Darn... my bad. The more generic version should be /vendor/. The . which I'd inadvertently placed in front of it will not be interpreted as root, but as a regex wildcard, so, while it shouldn't give any problems, it also isn't necessary.

<file>.</file>
<exclude-pattern>vendor/</exclude-pattern>

<!-- How to scan -->
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would recommend adding a link here to the PHPCS wiki so people will know where to find more information about these options.

You can either use the generic wiki link: https://github.com/squizlabs/PHP_CodeSniffer/wiki

Or links to both these pages as good starting points for people:

<arg name="extensions" value="php"/>
<arg name="parallel" value="8"/><!-- Enables parallel processing when available for faster results. -->

<!-- Rules: Check PHP version compatibility -->
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indentation is off here. Tabs vs spaces.

<arg name="extensions" value="php"/>
<arg name="parallel" value="8"/><!-- Enables parallel processing when available for faster results. -->

<!-- Rules: Check PHP version compatibility -->
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per the earlier comments, using PHPCompatibilityWP will be the better choice.

I'd also recommend adding a link to the PHPCompatibilityWP repo as a comment, again to help people to more easily find out more info: https://github.com/PHPCompatibility/PHPCompatibilityWP

Maybe also add a link for more info about what the testVersion means and how it works: https://github.com/PHPCompatibility/PHPCompatibility#sniffing-your-code-for-compatibility-with-specific-php-versions

You may also want to add a comment saying that people can change the testVersion to suit their project.

<config name="testVersion" value="5.3-"/>
<rule ref="PHPCompatibility"/>

<!-- Rules: WordPress Coding Standards -->
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Along the same lines as some of my other comments, you may want to add a link here to the WPCS repo and/or to the WPCS wiki page about configuring sniffs:

<property name="text_domain" type="array" value="my-plugin"/>
</properties>
</rule>
<rule ref="WordPress.WhiteSpace.ControlStructureSpacing">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is more a personal preference, than a recommended setting. I'm not sure if it belong in a scaffold.

<properties>
<property name="blank_line_check" value="true"/>
</properties>
</rule>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't looked at the scaffold in detail, but in case it also adds a PHPUnit test set-up, you may want to add an additional set of custom properties for that: https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/wiki/Customizable-sniff-properties#custom-unit-test-classes

<!-- How to scan -->
<arg value="sp"/> <!-- Show sniff and progress -->
<arg name="basepath" value="./"/><!-- Strip the file paths down to the relevant bit -->
<arg name="colors"/>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a side-note: colors will only work on certain platforms. Not sure by heart, but IIRC it works on Linux and Mac, but not on Windows.

@jrfnl
Copy link
Contributor

jrfnl commented Jul 20, 2018

Forgot to respond to this:

There are a couple of comments regarding WPCS 1.0.0 but IMO we are better if this is implemented now and an issue created to update when 1.0.0 comes out with additional improvements.

WPCS 1.0.0 was due to come out last week, but there's still one issue which needs to be fixed. Expect it very soon though.

All the same, for the ruleset as it is, AFAICS, no changes would be needed for WPCS 1.0.0, so you're good.

@jrfnl jrfnl mentioned this pull request Jul 20, 2018
also converts spaces to tabs
@GaryJones
Copy link
Contributor

The failure looks like some behat tests need updating to reference .phpcs.xml.dist (leading dot) instead of phpcs.xml.dist.

@NicktheGeek
Copy link
Author

@GaryJones @jrfnl will it be ok for this to not have the leading .? I think it is required to be automatically used but I want to make sure I'm understanding the reason.

@jrfnl
Copy link
Contributor

jrfnl commented Jul 20, 2018

@GaryJones @jrfnl will it be ok for this to not have the leading .? I think it is required to be automatically used but I want to make sure I'm understanding the reason.

Do you mean for the actual file name phpcs.xml.dist ? (in contrast to my remark about the exclude pattern #161 (comment) )

Yes, no problem.

Allowing a leading . for the filename was introduced in PHPCS 3.1.0 with a file loading order change in 3.1.1.

So for the custom ruleset with a leading dot to work, the minimum PHPCS requirement would have to be set at 3.1.0.

The file loading order (as of PHPCS 3.1.1) is:

  1. .phpcs.xml
  2. phpcs.xml
  3. .phpcs.xml.dist
  4. phpcs.xml.dist

In other words, not having the leading . now allows three different files to overrule the file.

Refs:

@GaryJones
Copy link
Contributor

will it be ok for this to not have the leading .?

And beyond what @jrfnl just said, whether it's right for PHPCS 3.1[.1] to be the minimum version for scaffolded plugins is a different matter, though for new plugins I don't see much reason why the default shouldn't be 3.3.

@NicktheGeek
Copy link
Author

I went ahed and updated the tests to solve for the file ext change

@@ -21,7 +21,7 @@ phpunit.xml.dist
multisite.xml
multisite.xml.dist
phpcs.xml
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You may also want to add .phpcs.xml here and possibly to the .gitignore file too ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jrfnl thanks! I added .phpcs.xml but .gitignore is already in the file higher up.

@schlessera schlessera added this to the 1.1.4 milestone Jul 29, 2018
@jrfnl
Copy link
Contributor

jrfnl commented Jul 29, 2018

FYI: in the mean time, both PHPCS 3.3.1 as well as WPCS 1.0.0 have been released.

@schlessera
Copy link
Member

Thanks to @NicktheGeek for the pull request, and thanks to @GaryJones & @jrfnl for the extensive review!

@schlessera schlessera merged commit a897a54 into wp-cli:master Jul 29, 2018
@schlessera schlessera changed the title change to .phpcs.xml.dist and update rules Update PHPCS default rule set Jul 29, 2018
danielbachhuber pushed a commit that referenced this pull request Nov 18, 2022
change to .phpcs.xml.dist and update rules
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants