Playground

The same scorer the CLI uses, compiled to WebAssembly and running in this tab. Your code is never uploaded. There is no server involved, and the module is fetched only once you open this page.

Nothing scored. Every unit here is trivial, or the source did not parse.

What you are looking at

Each row is a scoring unit: a function, method, closure, or the file’s top-level code. Click one to highlight the line it starts on.

The score is not a count of branches. Each break in linear flow costs +1, and then +1 more for every level of nesting it sits inside, which is why a callback pyramid climbs so fast. The scoring rules has the full increment table.

Each sample holds units of deliberately different weight, so you can see the range rather than one number. The PHP sample is the sharpest illustration: a four-arm switch scores 1, while three nested ifs score 6. Cyclomatic complexity would rank those the other way round.

Switching language changes the sample. The tool scoring identical logic identically across languages is a separate property, shown on the home page and covered in cross-language parity.

How it differs from the CLI

Two honest caveats.

Deeply nested code may be refused here but handled by the CLI. Every thread that parses natively reserves a 256 MB stack, because the walkers are recursive and generated code nests deeper than a default stack allows. WebAssembly’s stack is far smaller and cannot be grown the same way. Pathological input that the CLI scores fine may fail in this tab.

There are no thresholds, config or baselines here. The playground always reports every unit. bonsai-lint.toml, --over, domains and baselines are all part of the scan driver, which a single pasted buffer does not have.

The increments, the nesting rules, the unit naming and the suppression comments are all the same code.