PHP 8.6 arrives on November 19. DressCode already rewrites code for it. 16 days Upgrading to a newer PHP →
CS Get started

Format Your Code Step by Step

Your project already has a code style of its own, even if nobody ever formally wrote it down. DressCode measures your codebase to tailor a configuration around it, keeping the initial automated fix down to a manageable handful of files. These six steps take you from running dresscode init for the first time to an automated standard enforced by CI, Git hooks, your editor, and AI agents—one you can gradually tighten whenever you're ready.

If DressCode isn't installed yet, or you just want to take it for a spin first, Getting Started takes five minutes. Every option for init, check, fix, and baseline is listed in the command line reference.

1. Measure What Your Code Already Does

The conventional approach to adopting a coding standard is to pick an external standard off the shelf, run an automated fixer, and get a sprawling diff that touches half the codebase. Nobody can review a diff that large, and open feature branches immediately get bogged down in merge conflicts. DressCode takes the opposite route, meeting your code where it already is. In your project root, simply run:

dresscode init

The init command evaluates your code against all available standards and identifies the one under which an automated fix would touch the fewest files. It then analyzes the specific decisions where your code deviates from that standard and records the values that actually prevail in your codebase. The terminal report details what it found:

Standard   perCs (PER Coding Style), the nearest to your code by the files a fix changes, 13 under psr12; `--use` names another
Measured   your code departs from it in 3 decisions over 13 files; perCs as it is, with no decision below `use`, would rewrite 13 of them
As written indentation.unit: tab   your code, 92% of 13 files
           blankLines.beforeDeclaration: 2   your code, all 13 places
           braces.emptyBody.function: expanded   your code, all 26 places
Checked    all 13 files: a fix changes 1 file, 1 of them for the indentation, the line endings or the long lines the rest of the code has
...
Written    `dresscode.neon`

In this example, the closest matching standard is perCs, representing PER Coding Style 3.1. Notice the Measured line: applied out of the box, the standard would rewrite all 13 files. Once three decisions are tuned to match your actual conventions, the Checked line shows that an automated fix touches just a single file. That is the core idea: the standard provides the baseline, your codebase defines the exceptions, and every value clearly states its statistical foundation (your code, 92% of 13 files).

Even so, a legacy project can deviate from its closest standard in dozens of places—and the initial fix should never turn your repository upside down. That’s why init enforces a strict change budget: an automated fix is allowed to modify at most 1% of files by default (with a minimum of 2 and a maximum of 20; configurable via --budget). The only exceptions are indentation, line length, and line endings—these are normalized regardless of the budget because all other rules build upon them (files affected by these core rules are counted separately on the Checked line). If remaining fixes would exceed your budget, init defers contentious decisions and prompts you interactively, showing representative code snippets. It also prompts you when two standards are in a close tie. The recommended choice always comes first (option 1) and can be confirmed simply by pressing Enter. This default leaves your existing code untouched, so you risk nothing if you're unsure.

Outside an interactive terminal (or when passed --yes), init skips prompts and automatically chooses the recommended defaults. It prints each deferred question on a Your call line, formatted as a ready-to-use dresscode.neon snippet or as a CLI command to choose the alternative. To measure against a specific standard directly, specify it up front: dresscode init --use nette. If your project already uses PHP_CodeSniffer, PHP CS Fixer, or Laravel Pint, init inspects their existing configurations as well (see Migrating to DressCode to translate existing rules instead). Full details can be found on the init command page.

2. Read and Adjust the Configuration

The init command generated a dresscode.neon file in your project root. Setting aside excluded paths and namespace declarations, it looks like this:

# made to measure by `dresscode init`; run it again to see what has moved since, it writes nothing over this file
use: perCs   # PER Coding Style, of the standards the one a fix changes the fewest files of your code under

paths: [src, tests]

indentation:
	unit: tab                # your code, 92% of 13 files

braces:
	emptyBody:
		function: expanded   # your code, all 26 places

blankLines:
	beforeDeclaration: 2     # your code, all 13 places

The file answers two straightforward questions. The use key defines your visual foundation: it names the base standard, followed optionally by sets such as cleanup that target code quality beyond formatting. The keys below it explicitly document where your project does things differently. Any decision not mentioned in the file inherits its behavior from the standard.

Each key represents a precise decision path—the exact same path shown next to findings in terminal reports. If a setting is unfamiliar, ask about it: dresscode explain braces.emptyBody.function displays its purpose, supported values, its current setting in your project, and how major standards treat it. Running dresscode config shows the complete resolved configuration with every active decision and its source layer.

You can modify any value at any time, or delete a line to let the standard govern it. Before saving a change permanently, test it in a dry run: dresscode check --set literals.quotes=single --only literals.quotes --diff previews what enforcing single quotes would change without modifying files. The value keep means “do not check” and turns off a decision completely, even if required by the standard. Everything the configuration file can express is covered on the Configuration page.

3. The First Fix as a Commit of Its Own

Before running your first automated fix, commit any in-progress work or ensure you have a clean Git working tree so the diff isolates changes made by DressCode. Then preview the changes and let the tool do its work:

dresscode check --diff
dresscode fix

check --diff displays the planned changes without touching the disk; fix applies them directly. Every modified file is marked rewritten in the output. Below each file, the tool lists anything that cannot be resolved automatically—such as a non-standard method name that would require updating calls across the entire project.

Commit the result alongside dresscode.neon, which documents the rationale, and without any unrelated code edits. Nobody needs to scrutinize this commit line by line in code review—it is enough to know that it contains purely automated formatting. Future git blame lookups on reformatted lines will point directly to this formatting commit rather than cluttering subsequent feature commits. Thanks to the change budget, this commit stays small, minimizing merge conflicts with open branches. If you intentionally raised the budget or changed multiple major conventions at once, split the cleanup into a series of focused commits by set or section (see Cleaning Up Old Code Step by Step).

4. What No Rule Fixes

Following an automated fix, check may still highlight a few issues requiring human intervention: a method named get_total that should use camelCase, a risky fix your project hasn't yet permitted, or a line exceeding file.lineLength that cannot be safely broken automatically. There are three clean ways forward:

If there are only a handful of occurrences, resolve them manually. If a rule simply shouldn't apply to a specific line, suppress it in-place with // dresscode:ignore naming.method and append your reason after two dashes. And if the rule is correct but you don't have time to refactor legacy code right now, record the remaining issues in a baseline:

dresscode baseline

Baseline with 312 violations written to `dresscode-baseline.neon`.

From that moment on, only newly introduced violations will be reported. The baseline records only what an automated fix leaves behind, which is why it should always be generated after running fix; if an automated repair could still resolve an issue, baseline will refuse to run and prompt you to run fix first. The distinction between suppressions and baselines is critical: a suppression directive says “this rule is invalid here” and disables automated fixes, whereas a baseline says “we cannot fix this debt yet” and never prevents fixes from running. Baselines are meant to shrink over time; whenever a baselined issue is resolved, DressCode will notify you that the entry is stale. See Suppressions and the Baseline for details.

5. Keep It That Way

A standard that relies on developers remembering to run a command will inevitably erode. Let the tools you already use enforce it automatically:

  • Continuous Integration (CI) runs dresscode check on every push; any styling violation exits with code 1 and fails the job. On GitHub Actions, findings appear as native inline annotations directly on the pull request diff (see Continuous Integration).
  • A Git hook checks only staged files before commit, staying completely silent as long as the code is clean (see Git Hooks).
  • Your editor reformats files on save via dresscode fix --stdin. This works seamlessly in PhpStorm, VS Code, and any editor supporting formatting over standard input (see Editors and IDEs).
  • AI agents using the php-fixer plugin in Claude Code or Codex ensure every file modified by the agent is instantly formatted to your project standard (see AI Agents).

All four integrations read the exact same dresscode.neon file. The server, Git hooks, developer editors, and AI agents all hold your codebase to the identical standard. Check Integrations for recommendations on what to set up first.

6. Tighten It Over Time

The configuration generated by init captures your codebase as it was on that day—pragmatic compromises included. Decisions deferred by the change budget remain in the file as keep accompanied by a comment like not checked: a fix would change … and the exact file count. When you're ready to address one, preview it first and land it in a dedicated commit:

dresscode check --set literals.quotes=single --only literals.quotes --diff
dresscode fix --set literals.quotes=single

The first command previews what the decision would change without writing to disk. The second runs your entire configuration with that single rule enabled, ensuring the resulting edits are immediately formatted according to your broader standard. Then replace keep with the new value in dresscode.neon and commit both together (see Introducing a New Decision in One Commit).

Values that init measured directly from your code can follow the same path. Over time, those values may reflect legacy conventions that your team has outgrown. When you want to align with the standard's defaults, simply delete the overriding line from dresscode.neon and run fix. Sets work the same way: dresscode check --use cleanup --diff previews what the cleanup set would change before you add it permanently to the use key.

After updating DressCode or after months of active development, run dresscode init again. It will never overwrite an existing configuration file. Instead, it re-measures your project against the standard referenced in your configuration across all checked paths. It will report every decision it would configure differently today (including the file count an update would touch) and highlight custom overrides in your file that your code has naturally come to follow anyway. If everything remains aligned, it confirms that your configuration is up to date:

Compared   the code with the standard and the decisions of `dresscode.neon`, over the files it checks
Moved      nothing: `dresscode.neon` says what init measures

`dresscode.neon` exists, so nothing is written; `dresscode check --set path=value` shows what a value would change.

Where to Go Next

Show on GitHub · Report a problem with this page on GitHub · Nov 2, 2026