rtCamp Coding Standards D

The D is for David, the standards are for everyone.

---

Warning

This is an experimental project by @justlevine that is not (yet?) endorsed or supported by rtCamp.

---

A compact collection of PHPCS rulesets and sniffs for enterprise WordPress projects. It combines and curates rules from:

• WordPress Coding Standards
• Automattic VIP Coding Standards
• Slevomat Coding Standard
• PHPCompatibility & PHPCompatibilityWP

Why use Coding Standards?

Consistent coding standards reduce bugs, prevent common mistakes, and lower technical debt. They speed up reviews and maintenance so teams can ship reliably. Most importantly, they let us spend us to spend less time writing, debugging, and reviewing code, and more time shipping important and scalable features.

Note

AI code assistants and agentic tools make strict and consistent coding standards more important than ever:

• A project's codebase and tooling provide stronger context and guardrails than any AGENTS.md or external skill docs.
• Agents and harnesses can use the tooling directly to write higher-quality code that follows the project's standards and conventions.
• Developers can quickly validate agent-generated code to avoid subtle bugs.

Why use these Coding Standards?

• Ensure consistent, maintainable code across teams.
• Catch common bugs and reduce technical debt.
• Provide autofixable sniffs and practical guardrails for developers and AI tools.

Rulesets

• rtCamp: the full superset with all of the sniffs in the project.

  🎯 Use this by default and customize as needed, unless you have a particular reason to use or compose the others.

• rtCamp-Minimum: Essential sniffs for enterprise-ready code. All rtCamp code should pass this.

• rtCamp-Basic: Everything in rtCamp-Minimum plus practical, autofixable sniffs. This is recommended for client projects where we don't know the skill level of the developers who will be maintaining the project after handoff.

• rtCamp-Extra: rtCamp-Basic plus additional quality-focused sniffs for internal projects that prioritize higher standards without rtCamp-Strict's rigidity.

• rtCamp-Strict: rtCamp-Basic plus stricter functional sniffs for maximum quality and maintainability. This is recommended for public plugins and themes, or any project where you want to ensure the highest standards of code quality.

• rtCamp-Docs: Doc-block and comment sniffs to ensure clear, well-documented code. This is recommended for any project where you want to ensure that your code is well-documented and easy to understand - by developers and AI agents alike.

Installation

Recommended via Composer:

composer require --dev rtCamp/coding-standards-d

This will install the latest compatible versions of PHPCS and all the external sniffs and rulesets, so there is no need to include them in your dependencies list.

We recommend the PHP_CodeSniffer Standards Composer Installer Plugin, which handles the registration of all of the installed standards, so there is no need to set the installed_paths config value manually, for single or multiple standards.

For more information about installation and usage, see the WPCS readme.

Configuring your project

Tip

To quick-start your project, you can copy the example config file to your project root and rename it to .phpcs.xml.dist, then update the individual values as explained below.

Key settings to configure in your local file:

• testVersion: minimum PHP version to test (we recommend PHP 8.2+ unless constrained).
• minimum_wp_version: lowest WordPress version you support.
• WordPress.WP.I18n.text_domain: recommended format rt-<project-name>.
• WordPress.NamingConventions.PrefixAllGlobals: list of project prefixes.

Special configurations

• Non-WPVIP hosts: [@todo]
• PSR-4 autoloading: [@todo]
• Test files: [@todo]

Development & support

Add a CONTRIBUTING.md or DEVELOPMENT.md when ready. Meanwhile, open issues on GitHub or contact David Levine.

Versioning

This project follows Semantic Versioning (MAJOR.MINOR.PATCH), where:

• MAJOR: breaking changes.
• MINOR: new rules, deprecations, or behavior changes that may increase lint errors.
• PATCH: bug fixes, docs, and other non-breaking tweaks.

Because code quality tooling can make "breaking" ambiguous, we follow Eslint's policy ):

• PATCH releases are for bug fixes, rereleases, documentation updates, and other non-user-facing changes that are intended to not break your lint build.
• MINOR releases may add new rules/sniffs and deprecate or fix existing rules, and might cause existing code to fail linting.
• MAJOR release contain breaking changes such as: renaming/splitting rulesets, adding/removing/moving rules, or major dependency bumps. These changes may cause existing code to fail linting and require changes to your config or CI workflow.

Minor releases may increase reported linting errors. For projects without a lockfile, pin the dependency with a tilde(~) in composer.json to receive patch updates only, e.g. "rtcamp/coding-standards-d": "~1.1.0".

Automated Releases

This project uses release-please to automate versioning and releases. To trigger a release, use Conventional Commits:

• feat: for MINOR releases (new rules, behavior changes).
• fix: for PATCH releases (bug fixes, dependency updates).
• Commits with ! or BREAKING CHANGE: in the footer for MAJOR releases.

Releases are automatically managed via a "Release PR". Merging this PR will tag the release, create a GitHub Release, and update the CHANGELOG.md.

Tip

Dependabot is configured to use the fix(deps): prefix for all updates to ensure production dependency changes trigger a release. For development-only updates, you can manually change the PR title to chore(deps): before merging if a version bump is not desired.

Important

These guidelines apply to most PHPCS ruleset libraries, including those we use in this project.

To avoid new lint errors when updating child dependencies (for example via composer update -W), add the library to your project's dev dependencies and pin it with ~ as well, e.g. "automattic/vipcs": "~3.1.0".

Care about quality code?