Most code quality tools are really good at finding individual problems.
They'll tell you about:
- Dead code
- Unused dependencies
- Complex functions
- Large files
- Style violations
These are all useful, and I use many of these tools myself.
But after working on larger codebases, I realized something was missing.
They tell me what is wrong.
Very few tools explain why a codebase is slowly becoming harder to maintain.
The Problem
Imagine opening a project and seeing this:
The analyzer tells you:
- 180 dead code locations
- 47 oversized functions
- 12 dependency hotspots
- 4 circular dependencies
That's useful.
But as a developer, my next question is always:
Why are these problems appearing?
Looking Beyond Individual Warnings
Technical debt isn't just about a long function.
Sometimes the real issue is structural.
For example:
- One module becomes the dependency hub for the entire application.
- Features that should be independent slowly become tightly coupled.
- A single file grows because every new feature lands there.
- Circular dependencies appear between modules that were originally separate.
Those patterns are difficult to notice by reading files individually.
Why I Chose AST Analysis
Instead of searching source code with regular expressions, I parse the project into an Abstract Syntax Tree (AST).
That allows the analyzer to understand:
- Functions
- Modules
- Imports
- Calls
- Type definitions
- Relationships between files
Rather than treating files as plain text.
What the Analyzer Looks For
The current implementation detects patterns such as:
- Dead code
- Oversized functions
- Dependency hotspots
- Circular dependencies
- Complexity hotspots
- Structural relationships across the project
Instead of reporting isolated warnings, it tries to build a picture of the overall architecture.
Existing Tools Are Still Great
This isn't meant to replace tools like Clippy, cargo-udeps, or SonarQube.
Those tools solve different problems extremely well.
My goal is different.
I want to answer questions like:
- Why does this module keep growing?
- Why does every feature touch the same files?
- Which parts of the architecture are becoming bottlenecks?
- Where is technical debt accumulating before it becomes obvious?
Building It
The analyzer is written in Rust and is currently part of PunamIDE.
The most interesting challenge hasn't been parsing Rust syntax.
It's been deciding which structural metrics actually represent technical debt rather than simply producing more warnings.
Finding the right balance between useful insight and information overload is much harder than building another linter.
What's Next
I'm continuing to experiment with additional architectural metrics and improving how results are visualized.
I'd also love to hear from other developers.
When you think about technical debt, what patterns do you wish your tools detected automatically?
Top comments (0)