WordPress-Coding-Standards | PHP_CodeSniffer rules to enforce WordPress | Content Management System library

A couple of pointers:

• The phpcs.xml file (can also be phpcs.xml.dist and other similar variations that have a preferred order) (not ruleset.xml), should be in the root of your project code, not in the directory you installed WPCS.

• The VS Code config would then be the path (absolute or relative) to that phpcs.xml file:

  "phpcs.standard": "/path/to/project/phpcs.xml"

  or

  "phpcs.standard": "./phpcs.xml"

You'll still need to ensure that the phpcs executable you're referring to has got the WordPress standards registered.

Reference: https://marketplace.visualstudio.com/items?itemName=ikappas.phpcs

If you already installed the git-scm.com version, you can use my second favourite on top of it, Git for Windows (https://gitforwindows.org)

It will support your Git installation out of the box without messing around with environment variables and it uses Git Bash, which emulates a common Linux command line, so most git commands you will find around on the web will work for you

If you do this, you shouldn't try to run git directly from the Windows command line, but from the Git Bash command line, which will be accessible everywhere in Windows from the right click menu

First, you don't need to require PHP CodeSniffer explicitly, because wp-coding-standards/wpcs pulls it automatically.

composer.json

Ok,

I digged into the topic and pparently I didn't have Node.js installed so I couldn't manage any npm packages. After installing Node.js I was able to install WordPress-Coding-Standards. Unfortunately I installed the wrong package at first, which was eslint-plugin-wordpress. After trying to set it up eslint started giving me plenty of errors. Then I found out (with a little help from guys on Github) that there are other WordPress Coding Standards plugin for eslint - eslint-config-wordpress which I installed as well. Now everything works like a charm. It's good to learn something new everyday.

Thanks, Dan.

Greg Sherwood’s comment above pointed me in the right direction. The two commands were symlinks pointing at different installs. I figured this out by running which phpcs and which phpcbf and running readlink (to see if they were symlinks) on the results.

which phpcs gave me /usr/local/bin/phpcs and readlink /usr/local/bin/phpcs gave me the path to the actual executable.

Once I figured out that phpcbf was a symlink to an executable in a different install I deleted it and replaced it with a symlink to phpcbf in the same install as phpcs, which solved my issue.

Historically, WordPress has avoided cleaning up the Core code style, for several reasons:

• The tools for checking coding standards were not particularly reliable. This has changed in recent years, with the WordPress Coding Standards (WPCS) project maturing, and many of the little edge cases being fixed in PHPCS.
• With no reliable automated tools, this would be a manual job, requiring many commits. This causes unnecessary code churn, and makes it harder to look through revision logs.
• It just hasn't been a high priority. ~4% of WordPress' PHP violates the coding standard, so most folks just don't encounter it.

With the tools maturing, that position changed recently, there's now an in-progress effort to get PHPCS and WPCS working with WordPress Core. With appropriate automated testing, WordPress will continue to match it's own coding standards in the future.