• Installation
• Setup
• Usage
  • Use in an IDE
• Developing this standard
• Credits

Code& Coding Standards is a project with rulesets for code style and quality tools to be used in Code& WordPress projects.

It combines PSR-12 with WordPress Coding Standards and additional checks. Imports require separate use statements. Class names may use PascalCase or capitalized words separated by underscores.

Whenever there's a conflict between PSR and WPCS, we almost always prefer PSR.

PHP 8.2 or later is required to install and run these coding standards.

Merge this repository and plugin permission into the WordPress project's composer.json, preserving its existing entries:

{
  "repositories": [
    {
      "type": "vcs",
      "url": "[email protected]:teamcodeand/codeand-wp-coding-standards.git",
      "no-api": true
    }
  ],
  "config": {
    "allow-plugins": {
      "dealerdirect/phpcodesniffer-composer-installer": true
    }
  }
}

From the project root, install the standard and the plugin that registers its rules with PHP_CodeSniffer:

composer require --dev teamcodeand/codeand-wp-coding-standards:dev-main dealerdirect/phpcodesniffer-composer-installer:^1.2

Verify registration with vendor/bin/phpcs -i. The list should include codeand, WordPress, PHPCompatibilityWP, VariableAnalysis, PSR2R and SlevomatCodingStandard. Let the Composer plugin manage installed_paths; setting it to only the Code& directory hides the other required standards.

First, create phpcs.xml on project root:

<?xml version="1.0"?>
<ruleset name="codeandbedrock">
    <!-- Check all files under app/ (assuming Bedrock) -->
    <file>./web/app/</file>

    <!-- Show colors in console -->
    <arg value="-colors"/>

    <!-- Show progress and sniff codes in all reports; Show progress of the run -->
    <arg value="sp"/>

    <!-- Scan only PHP files -->
    <arg name="extensions" value="php"/>

    <exclude-pattern>vendor/</exclude-pattern>

    <!-- TODO: Probably change everything below! -->
    <!-- TODO: Exclude specific rules if necessary -->

    <!-- Use Code& WP Coding Standards -->
    <rule ref="codeand">
        <!-- And only inspect custom stuffs -->
        <include-pattern>/web/app/plugins/myplugin/*</include-pattern>
        <include-pattern>/web/app/themes/childtheme/*</include-pattern>
    </rule>

    <!-- TODO: Define minimum supported WordPress version -->
    <config name="minimum_supported_wp_version" value="5.2"/>

    <!-- TODO: Define expected text domains -->
    <rule ref="WordPress.WP.I18n">
        <properties>
            <property name="text_domain" type="array">
                <element value="my-plugin"/>
                <element value="my-theme"/>
                <element value="woocommerce"/>
                <element value="sage"/>
            </property>
        </properties>
    </rule>
</ruleset>

For Bedrock, adjust the include patterns to cover the project's own plugins, themes and MU plugins. The <file> entries determine which paths PHPCS searches; the include patterns determine where the rules apply.

If a project adds a separate scoped PHPCompatibilityWP rule, declare it before codeand and list every path that needs compatibility checking, including the custom-code paths. PHPCS applies these include patterns when the checks are first imported; adding another scoped import later does not extend their coverage.

For a standalone plugin, use <file>./</file> and <rule ref="codeand"/> instead of the Bedrock file entry and scoped codeand rule above. Keep the vendor/ exclusion and set the plugin's WordPress minimum and text domain.

Either define the project's composer scripts:

{
  "scripts": {
    "test": [
      "phpcs"
    ],
    "fix": [
      "phpcbf"
    ]
  }
}

Run the commands:

$ composer test
$ composer fix

Or alternatively, set this up in your IDE to check your code as you're working on it. You'll probably find a guide for how to do that in the WPCS Readme under Using PHPCS and WPCS from within your IDE

From a checkout of this repository, run composer install followed by composer test using PHP 8.2 or later. The regression checks cover naming, imports, variable analysis, spacing and project file scope. GitHub Actions runs them on PHP 8.2 for non-draft pull requests targeting develop, master or main, and for pushes to main. Draft PRs are skipped; marking a PR ready for review triggers the checks.

Largely based on Itineris WP Coding Standards created by Tang Rufus. Also makes use of some rules from Human Made with a smattering of input from Code&.