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
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions src/Scaffold_Command.php
Original file line number Diff line number Diff line change
Expand Up @@ -575,7 +575,7 @@ private function get_output_path( $assoc_args, $subdir ) {
* * `bin/install-wp-tests.sh` configures the WordPress test suite and a test database.
* * `tests/bootstrap.php` is the file that makes the current plugin active when running the test suite.
* * `tests/test-sample.php` is a sample file containing test cases.
* * `phpcs.xml.dist` is a collection of PHP_CodeSniffer rules.
* * `.phpcs.xml.dist` is a collection of PHP_CodeSniffer rules.
*
* ## OPTIONS
*
Expand Down Expand Up @@ -706,7 +706,7 @@ function plugin( $args, $assoc_args ) {
* * `bin/install-wp-tests.sh` configures the WordPress test suite and a test database.
* * `tests/bootstrap.php` is the file that makes the current plugin active when running the test suite.
* * `tests/test-sample.php` is a sample file containing the actual tests.
* * `phpcs.xml.dist` is a collection of PHP_CodeSniffer rules.
* * `.phpcs.xml.dist` is a collection of PHP_CodeSniffer rules.
*
* Learn more from the [plugin unit tests documentation](https://make.wordpress.org/cli/handbook/plugin-unit-tests/).
*
Expand Down Expand Up @@ -759,7 +759,7 @@ public function plugin_tests( $args, $assoc_args ) {
* * `bin/install-wp-tests.sh` configures the WordPress test suite and a test database.
* * `tests/bootstrap.php` is the file that makes the current theme active when running the test suite.
* * `tests/test-sample.php` is a sample file containing the actual tests.
* * `phpcs.xml.dist` is a collection of PHP_CodeSniffer rules.
* * `.phpcs.xml.dist` is a collection of PHP_CodeSniffer rules.
*
* Learn more from the [plugin unit tests documentation](https://make.wordpress.org/cli/handbook/plugin-unit-tests/).
*
Expand Down Expand Up @@ -889,7 +889,7 @@ private function scaffold_plugin_theme_tests( $args, $assoc_args, $type ) {
$to_copy = array(
'install-wp-tests.sh' => $bin_dir,
'phpunit.xml.dist' => $target_dir,
'phpcs.xml.dist' => $target_dir,
'.phpcs.xml.dist' => $target_dir,
);

foreach ( $to_copy as $file => $dir ) {
Expand Down
44 changes: 44 additions & 0 deletions templates/.phpcs.xml.dist
Original file line number Diff line number Diff line change
@@ -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.

<description>Generally-applicable sniffs for WordPress plugins.</description>

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


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

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

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

<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!

<arg name="report" value="summary"/>
<arg name="report" value="source"/>

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

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


<!-- 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:

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

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

</properties>
</rule>
<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.

</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

</ruleset>
20 changes: 0 additions & 20 deletions templates/phpcs.xml.dist

This file was deleted.