SSimplicityToolsMeasure complexity before it measures your team.

Samples

Samples hub

The samples are teaching assets, not filler. Use them to show what healthy shape looks like, to compare metric output, and to validate the CLI flow before you point the tool at your own solution. Two of them are ends of a spectrum; the third is the shape most real solutions actually have.

Sample solutions

Each sample is already used in the docs. This hub makes them easier to find from the site.

Healthy shape

Sample.Simplified

A lean reference solution with a small project graph, low complexity, and a clear primary path. 2 projects, 19 files.

dotnet simplicity analyze samples/Sample.Simplified/Sample.Simplified.sln
Anti-pattern reference

Sample.OverEngineered

A deliberately heavy solution that makes abstraction depth, drift, and report storytelling obvious. 12 projects, 65 files.

dotnet simplicity analyze samples/Sample.OverEngineered/Sample.OverEngineered.sln
Full toolkit coverage

Sample.ClaimsPortal

The realistic middle: a claims intake service that builds clean and passes its tests, yet trips all seven analyzers and fails a filter. 8 projects, 49 files.

dotnet simplicity analyze samples/Sample.ClaimsPortal/Sample.ClaimsPortal.sln

Recommended teaching flow

Use the samples to make the tool value concrete before you ask a team to trust the numbers on their own codebase.

  1. Run analyze on the simplified and over-engineered samples and compare the metrics summary. The gap between them is the range the tool measures.
  2. Generate a report for the over-engineered sample so the visual story becomes obvious.
  3. Run analyze and budget on Sample.ClaimsPortal. It reports 1 of 3 dimensions within budget, which is the conversation most teams actually need to have — the other two samples are too clean or too broken to argue about.
  4. Use budget and diff to show how the toolkit supports ongoing decisions, not just snapshots.

Seeing every tool at once

Sample.ClaimsPortal is the only sample wired for the whole toolkit.

  • All seven analyzer diagnostics fire, including a deliberate non-hit: an interface with two implementations that SF0001 correctly leaves alone.
  • The three filter evaluators return a mixed verdict — TwoAmTest passes, HalfRule fails, PrimaryPathFirst passes narrowly — instead of all green or all red.
  • It is the only sample shipping a simplicity.json and a fully documented .editorconfig, so it doubles as a configuration starting point.
  • A companion console project calls the Metrics, Filters, and TCA libraries directly, which is the only worked example of the TCA calculator.

The sample'sREADMEhas the per-tool walkthrough, a table naming the file and reason behind every diagnostic, and a six-step exercise that fixes the solution while you watch the numbers move.