PHP_Depend measures design quality in PHP code, not code style

A JDepend port aimed at design feedback rather than defects

PHP_Depend takes an existing idea from the Java world and reimplements it for PHP. The project describes itself as an adaptation of the established Java development tool JDepend, and states its purpose plainly: it shows you the quality of your design in terms of extensibility, reusability and maintainability.

That positioning matters, because it separates the tool from the crowded category of PHP quality checkers. A linter tells you that a line is too long or violates a naming convention. A static analyser tells you that a call may receive the wrong type. PHP_Depend is interested in the shape of the design: how classes depend on each other, how easily parts can be reused, and how hard the whole thing is to extend. The value is that it gives you a number for something reviewers usually argue about in prose.

The audience is a PHP team that has already dealt with linting and type checks and now wants the coarser view. It also fits anyone migrating design habits from Java, since the underlying model is inherited rather than invented for PHP. It does not fit a small project looking for a single quick quality gate, because design metrics take work to interpret and to argue about.

One point of caution about the documentation. The README is short and mostly carries badges plus links, so it tells you what the tool measures but not how to configure it. The getting started guide is the place to look, linked from the README at pdepend.org/documentation/getting-started.html.

The repository layout shows a full tool, not a single script

The top level of the repository is worth reading before you install anything, because it says more about the project than the README does.

The core separation is standard for a packaged PHP tool. src/ holds the source, bin/ holds the command entry points, conf/ holds configuration handling, resources/ holds the assets the reports need, and tests/ holds the test suite. Two more directories stand out. scripts/ holds development helper scripts, and site/ holds what appears to be the documentation site itself, which is consistent with the project publishing documentation at pdepend.org.

Then there is the tooling that tells you how the maintainers work. A composer.json at the root makes this a Packagist package, and the README links the Packagist distribution page for it. A build.properties file sits alongside a Vagrantfile, suggesting a packaged build with a virtual machine based development environment. A .gitmodules file means some dependencies are pulled in as git submodules rather than resolved by the package manager.

None of this is described in prose anywhere, but together the entries describe a mature library project with a distribution channel, a development environment, and its own quality infrastructure.

The config files reveal which tools the project runs on itself

The most revealing files in the repository are the ones that configure other analysers.

PHPStan is configured through phpstan.neon, and the presence of three separate baseline files is telling. There is a general baseline at phpstan-baseline.neon.php, plus two baselines split by Symfony version, one for Symfony post-7 and one for Symfony pre-7. In practice that means the project maintains its PHPStan findings against two different Symfony baselines, which is what you would expect from a library that has to pass static analysis under more than one major dependency version.

Coding style is handled separately. phpcs.xml.dist configures PHP_CodeSniffer, and .php-cs-fixer.php configures the php-cs-fixer tool. The use of the .dist convention on both files is the standard way to ship a configuration that a project copies and then adjusts, rather than one that is forced on everyone who installs the package.

For a user of PHP_Depend this matters in a practical way. The maintainers are running a type analyser, a code sniffer and an auto fixer over their own code, which says something about the standards the tool is expected to meet. It also gives you a picture of the local quality tooling that PHP_Depend sits next to, which is useful context when you decide where it belongs in your pipeline.

Where to get it, given that the README lists no install command

The README contains no installation command, no composer require line and no sample invocation. It links two places instead: the documentation site, with a getting started guide at pdepend.org/documentation/getting-started.html, and the Packagist distribution page for the package.

That is the honest answer for installation. PHP_Depend is distributed through Packagist, so the package name to look for is the one in the README badge:

pdepend/pdepend

If you want to see what a configured project looks like, the repository ships ready to copy configuration files rather than only documentation:

pdepend.yml.dist
composer.json

The .dist suffix on the configuration file follows the same convention as phpcs.xml.dist, which is to say it is a template meant to be copied into your own project and edited.

What you will not find in the repository is a worked example of a pdepend.yml file with real values in it, and the README does not enumerate the configuration keys. Anyone planning to run this in CI should expect to read the getting started guide rather than to infer the configuration from the source tree.

Version 3.0.0 after a long gap from the 2.x line

The release history explains the shape of the project's maintenance. Version 3.0.0 was published on 2026-10-01. Before that, the most recent releases were 2.16.2 on 2023-12-17 and 2.16.1 on 2023-12-10, a gap of close to three years between the 2.16.x line and the 3.0.0 release.

That gap is the single most important fact for anyone considering adoption, and it cuts both ways. On one side it suggests the 3.x line is a substantial rework rather than a routine increment, and the presence of UPGRADE.md at the top level of the repository says as much. On the other side, a project that spent three years between a 2.16.x patch release and a 3.0.0 major release is a project whose long term direction has to be judged from a single recent data point.

The default branch is 3.x, so the current development line and the current major version line agree. The last push was on 2026-10-11, ten days after the 3.0.0 release and not long before this review, and the repository is not archived. A CHANGELOG.md is present for the detailed history.

One small inconsistency shows the transition is still settling. The README badges for code coverage and code quality point at a master branch, while the default branch is 3.x. Anyone scripting against those badges should check which branch the workflow actually runs on rather than trusting the link.

What the design metrics cannot tell you

The honest limitation of PHP_Depend is that it produces numbers about structure, and numbers about structure are easy to over-trust. A score for extensibility or reusability can improve while the code becomes harder for the next person to read, and a maintainability figure is only meaningful relative to the other projects you compare it with.

The documentation gap compounds this. The README states the three dimensions the tool covers but does not define them, does not list the metrics behind them, and does not explain what the output looks like. The getting started guide is where that lives, and reading it is not optional if you plan to act on the results.

There is a second constraint that follows from the design. This is a source level analyser, which means it needs the code to parse and the project to be resolvable enough to build a dependency graph. Neither the README nor the repository layout says anything about how it handles generated code, vendor directories, or projects whose dependencies are resolved at runtime rather than statically. If your codebase relies heavily on dynamic class resolution or on dependency injection containers, the accuracy of the graph the tool builds is exactly the thing you will want to check before trusting the output. The documentation does not address that case, so it remains an open question rather than a known limitation.

Where PHP_Depend sits against the tools already in most PHP pipelines

The realistic alternative for most teams is not another design tool, it is to keep running what they already run and accept that design quality stays a review topic. Concretely, a PHP project of any size usually carries PHPStan for type level findings and PHP_CodeSniffer for style, and both are configured inside this very repository, which makes them a fair point of comparison.

The difference in approach is the level of question asked. PHPStan inspects expressions and types inside functions. PHP_CodeSniffer inspects the shape of the source text. PHP_Depend inspects the relationships between classes and packages, which is a question neither of the others answers. Because it inherits the JDepend model, you also get a metric vocabulary that Java teams already understand, which saves the argument about what a number should mean.

The cost side is equally concrete. Design metrics are cheap to compute but expensive to act on, and they only tend to pay off where there is a shared definition of good design in the team. In a codebase that nobody reviews for structure, the report becomes a dashboard nobody reads, and PHPStan plus PHP_CodeSniffer would have caught more real problems for less effort.

For teams with a large legacy PHP estate, that is the deciding factor. PDepend-style metrics can highlight the parts of a codebase that are entangled, which is exactly the information needed to plan a refactoring. For a young codebase with a good review culture, the same report mostly confirms what the team already knows.

Editorial conclusion

PHP_Depend suits PHP teams that want design level feedback alongside the style and type checks they already run, and it suits anyone who values a metric that came from a proven Java tool and accepts the overhead of learning a second analyser. It is the wrong tool for a project that only needs linting or static type checking, since PHPStan and PHP_CodeSniffer configuration already present in this repository address different questions and run far more cheaply. Before adopting it, read the getting started guide linked from the README, decide whether the design metrics will change anything in your review process, and confirm you can live with the jump from the 2.16.x line to 3.0.0 by reading UPGRADE.md in the repository before pinning a version.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. pdepend/pdepend on GitHub
3. Project website
4. README
5. Releases