Performant static analyzer for PHP, written in Rust. Catches common mistakes and enforces best practices with zero configuration required.

PHP codebases grow. As they grow, they accumulate technical debt — god classes that do everything, methods no one can follow, hidden complexity that breaks with every change. Traditional linters catch syntax errors and style issues, but they don't tell you if your code is maintainable.

Phanalist focuses on structural health. It measures what matters for long-term maintainability:

• Complexity metrics — cyclomatic complexity, cognitive complexity, LOC per method, nested paths
• Coupling & cohesion — Law of Demeter violations, god classes, data classes, fan-in/fan-out
• Object-oriented design — depth of inheritance, weighted methods per class, response for a class
• Readability — comment ratios, error suppression, method parameter counts

Think of it as a health checkup for your PHP code. It doesn't just tell you that something is wrong — each rule explains why it matters and how to fix it.

• 🚀 Fast — built in Rust, analyzes large codebases in seconds
• 🔍 31 built-in rules — covering complexity, style, design patterns, and more
• ⚙️ Zero config to start — works out of the box, configure only what you need
• 📄 Multiple output formats — text, json, sarif (for CI pipelines with inline PR annotations via GitHub Action), and codeclimate (for Code Quality platforms)
• 🔌 Extensible — adding a custom rule takes minutes

The simplest way to install Phanalist is to use the installation script:

curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/denzyldick/phanalist/main/bin/init.sh | sh

It will automatically download the executable for your platform:

$ ~/phanalist -V
phanalist 1.0.0

There are also multiple other installation options.

Add inline SARIF annotations to your PRs using the Phanalist GitHub Action:

name: Phanalist
on: [pull_request]
permissions:
  security-events: write
jobs:
  phanalist:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: denzyldick/phanalist-action@v1

To analyze your project sources, run:

~/phanalist

On the first run phanalist.yaml will be created with the default configuration and reused on all subsequent runs.

Additional CLI flags:

Use the --blame flag to see who is introducing and fixing violations in your codebase:

# Who has violations in their code currently
~/phanalist --blame

# See what changed in the last 30 days (Net column shows who is improving vs degrading)
~/phanalist --blame --since "30 days"

# See changes over the last year
~/phanalist --blame --since "1 year"

# Exclude bots
~/phanalist --blame --since "30 days" --exclude-author dependabot

# Sort by net improvements (who is adding the most value)
~/phanalist --blame --since "30 days" --sort net

The report shows a table with:

Sorting:

Use --sort to change the order: total (default, by volume), net (by net improvements), name, fixed, introduced.

How it works:

• Without --since: Looks at the current violations in your code and uses git blame to figure out who last touched each affected line. Engineers are credited with the violations in code they most recently worked on.
• With --since <date>: Takes a snapshot of your code as it was at that date, runs the same analysis on the old version, and compares the results. Violations that disappeared were "fixed" — violations that appeared were "introduced". Each change is attributed to the engineer who made it.

Output:

The report includes a summary table and a per-rule breakdown with colored counts (green for fixed, red for introduced).

The --blame flag works with --output-format json — the engineer data is included as an "engineer_report" field in the JSON output for use in pipelines or dashboards.

Requires a .git directory (discovered from the current working directory). Only files within --src paths are attributed.

A baseline lets you adopt phanalist on an existing codebase without fixing every finding at once. It freezes the current violations; later runs report only new ones, so CI stays green on known debt but fails on regressions.

Generate (or regenerate) the baseline:

~/phanalist --use-baseline phanalist-baseline.json --update-baseline

Then run against it (in CI, or locally):

~/phanalist --use-baseline phanalist-baseline.json

The baseline is a pretty-printed, stably sorted JSON file, so it produces clean diffs and merges. Each entry is keyed on the file, rule, and a stable message id with a count, so unrelated edits that shift line numbers do not invalidate it, and reworded message text does not either. When you fix violations, regenerate the baseline to shrink it.

enabled_rules: []   # empty = all rules active
disable_rules: []
exclude_paths: []   # paths skipped before any rule runs (see below)
rules:
  E0007:
    check_constructor: true
    max_parameters: 5
  E0009:
    max_complexity: 10
  E0010:
    max_paths: 200
  E0012:
    include_namespaces:
      - "App\\Service\\"
      - "App\\Controller\\"
    exclude_namespaces: []
    reset_interfaces:
      - "ResetInterface"
  E0015:
    threshold: 1
  E0016:
    max_complexity: 15
  E0024:
    max_loc: 30
  E0025:
    max_loc: 500
  E0026:
    min_ratio: 0.1
    max_ratio: 0.5
  E0027:
    max_methods: 15
    max_fields: 10
  E0028:
    max_getter_setter_ratio: 0.7
    min_methods: 3
  E0029:
    max_fan_out: 10
    max_fan_in: 20
  E0030:
    max_density: 0.3

• enabled_rules — whitelist of rules to run (empty = all)
• disable_rules — rules to skip
• rules — per-rule configuration options
• exclude_paths — files skipped before any rule runs, as directory prefixes (var/cache, bootstrap/cache) or globs (**/*.generated.php). Handy for framework caches and frozen code like migrations that would only add noise. Literal (non-glob) patterns that don't exist on disk trigger a warning at -v verbosity — a helpful catch for typos. Globs that match nothing are silently accepted.

Adding a new rule is straightforward — this tutorial explains how.

Read a series of chapters on https://dev.to/denzyldick to understand the project's internals — a great, easy-to-read introduction.

1. Write your own static analyzer for PHP.
2. How I made it impossible to write spaghetti code.
3. Detecting spaghetti code in AST of a PHP source code.
4. Getting Symfony app ready for Swoole, RoadRunner, and FrankenPHP (no AI involved).
5. Improve your CI output
6. Why using unserialize in PHP is a bad idea