Code Quality Tools Beyond Linting

[cleder]

The landscape of Python software quality tooling is currently defined by two contrasting forces: high-velocity convergence and deep specialization. The recent, rapid adoption of Ruff has solved the long-standing community problem of coordinating dozens of separate linters and formatters, establishing a unified, high-performance axis for standard code quality.

A second category of tools continues to operate in necessary, but isolated, silos. Tools dedicated to architectural enforcement and deep structural metrics, such as:

• import-linter (Layered architecture enforcement)
• tach (Dependency visualization and enforcement)
• complexipy, radon, lizard (Metrics for overall and cognitive complexity)
• module_coupling_metrics, lcom, and cohesion (Metrics for coupling and class cohesion)

These projects address fundamental challenges of code maintainability, evolvability, and architectural debt that extend beyond the scope of fast, stylistic linting. The success of Ruff now presents the opportunity to foster a cross-tool discussion focused not just on syntax, but on structure.

Specialized quality tools are vital for long-term maintainability and risk assessment. Tools like import-linter and tach mitigate technical risk by enforcing architectural rules, preventing systemic decay, and reducing change costs. Complexity and cohesion metrics from tools such as complexipy, lcom, and cohesion quantitatively flag overly complex or highly coupled components, acting as early warning systems for technical debt. By analysing the combined outputs, risk assessment shifts to predictive modelling: integrating data from individual tools (e.g., import-linter violations, complexipy scores) creates a multi-dimensional risk score. Overlaying these results, such as identifying modules that are both low in cohesion and involved in tach-flagged dependency cycles, generates a "heat map" of technical debt. This unified approach, empirically validated against historical project data like bug frequency and commit rates can yield a predictive risk assessment. It identifies modules that are not just theoretically complex but empirically confirmed sources of instability, transforming abstract quality metrics into concrete, prioritized refactoring tasks for the riskiest codebase components.

Reasons to Connect

Bring the maintainers and core users of these diverse tools into a shared discussion.

Increasing Tool Visibility and Sustainability: Specialized tools often rely on small, dedicated contributor pools and suffer from knowledge isolation, confining technical debate to their specific GitHub repository. A broader discussion provides these projects with critical outreach, exposure to a wider user base, and a stronger pipeline of new contributors, ensuring their long-term sustainability.

Let's start the conversation on how to 'measure' maintainable, and architecturally sound Python code.

And keep Goodhart's law: "When a measure becomes a target, it ceases to be a good measure" in mind ;-)

[gwdekker]

Interesting! In my python monorepo we use tach but looking for an alternative as it is no longer maintained. In addition we use polylith (https://davidvujic.github.io/python-polylith-docs/) tooling, and have some unit tests on top of some of the polylith results.

Regarding some of the tooling you mention above, I am thinking that a great first start for some use cases could maybe be to get ruff analyze graph stable (its still experimental) - seems like constructing that dependency tree could be a very nice building block for some of the tooling mentioned above to start using.

[gwdekker]

related: #20701

[CoderJoshDK]

Recently, the basedpyright maintainer made their own fork that they will supposedly be maintaining.
https://github.com/detachhead/dtach

[cleder]

I haven't heard of polylith before, it looks 😍

Just after I discovered tach and was excited about it, it became unmaintained 😢

ruff analyze graph looks promising.

[cleder]

Tach is back, and activey developed again at https://github.com/tach-org/tach

[cleder]

Here is another one, only a couple of months old:
pyscn - Python Code Quality Analyzer

🔍 CFG-based dead code detection – Find unreachable code after exhaustive if-elif-else chains
📋 Clone detection with APTED + LSH – Identify refactoring opportunities with tree edit distance
🔗 Coupling metrics (CBO) – Track architecture quality and module dependencies
📊 Cyclomatic complexity analysis – Spot functions that need breaking down
100,000+ lines/sec • Built with Go + tree-sitter

[cleder]

by @DaisukeYoda

[seddonym]

Hi there, thanks for starting the thread. I'm the maintainer of Import Linter and Grimp (a Rust-backed library which it uses for the heavy lifting). Also Impulse, a little library for visualizing the graph.

[allenanswerzq]

would love to see and learn how your projets work internally

[ntBre]

Yes, thank you for opening the discussion! I don't have much to add at the moment, but I'm excited to follow the thread and take a look at the tools mentioned 😄

[cleder]

https://github.com/allenanswerzq/llmcc
llmcc explores automated context generation through symbolic graph analysis.
To give you a high level architecture design for a project build a project level graph using page-rank pick the most important nodes, or find all depends on a symbol under a specific folder,
It bridges the semantic gap between human-written code/documents and AI model understanding, using modern compiler design principles.

[allenanswerzq]

thanks for collecting my project here, this is the generated design graph for ruff, not sure how good it represents, just having fun..

[allenanswerzq]

commands to reproduce if someone interested: ./target/release/llmcc --dir ../ruff --design-graph --pagerank --top-k 100

[cleder]

https://github.com/NathanDuboisset/importee
Python import checker with Rust backend. Checks import ordering rules in Python projects.
@NathanDuboisset

[NathanDuboisset]

I just created this one as a side project(it works for just one rule). I wanted to touch the rust part myself. I searched a tool like that, found the one by David Seddon, and wanted to use a rust approach to learn. Maybe will not be at the same level as the others. Happy to work on it with people though !

[cleder]

https://github.com/matzehuels/stacktower

Inspired by XKCD #2347, Stacktower renders dependency graphs as physical towers where blocks rest on what they depend on. Your application sits at the top, supported by libraries below—all the way down to that one critical package maintained by some dude in Nebraska.

[cleder]

Related for JS/TS (written in Rust)

Fallow turns a JS/TS repository into a trusted quality report: health score, changed-code risk, hotspots, duplication, architecture issues, dependency hygiene, and cleanup opportunities. It helps you answer:

What changed?
What got riskier?
What should I review?
What should I refactor?
What can be safely removed?

Fallow is built for maintainers, CI pipelines, editors, and AI agents that need structured evidence instead of guesses. No AI inside the analyzer. Fallow produces deterministic findings, typed output contracts, and traceable explanations that downstream tools can trust.

[cleder]

Deply is a static code analysis tool for Python that helps you communicate, visualize and enforce architectural decisions in your projects. You can freely define your architectural layers over classes and which rules should apply to them.

For example, you can use Deply to ensure that modules/packages in your project are truly independent of each other to make them easier to reuse.

Deply can be used in a CI pipeline to make sure a pull request does not violate any of the architectural rules you defined. With the optional Mermaid formatter you can visualize your layers, rules and violations.

by @Vashkatsi

[cleder]

flakydetector @Artem7898

FlakyDetector is a research-oriented tool designed to identify non-deterministic (flaky) tests in Python codebases. Instead of relying on historical CI execution data, the analyzer parses the Abstract Syntax Tree (AST) of the source code, extracts scientific features, and classifies them using a CatBoost ML model.

Unlike ordinary linters, FlakyDetector hunts for architectural anti-patterns: race conditions, resource leaks, global state dependencies, and high cyclomatic complexity (Test Smells).

[christianledermann-arch]

see also #26730

[cleder]

Most linters catch bad code inside files. Fensu catches architectural drift: code crossing the wrong boundary, living in the wrong module, or growing into the wrong shape.

As a repository grows, code moves, lessons get forgotten, and the mental map decays. Tests preserve behavior and types preserve interfaces. Fensu makes the repository's architectural expectations executable.

Fensu enforces:

• which layers may import which;
• what each module or role file may contain;
• whether orchestrator functions stay small;
• whether dataflow and mutation are explicit;
• whether names such as validate_* mean what they claim.

It ships a coherent default architecture rather than a blank rule framework, then lets projects disable, extend, or replace parts deliberately.
@kvlonge

[kvlonge]

Oh, I didn't expect someone to find my library before I had announced it on anything (doing a formal announcement in a week or so).

It's awesome to see I am not the only one thinking about this though!

My thoughts on the matter are that a lot of time is wasted on reviews to check stuff that could have been caught with deterministic checks as to the code structure / architecture, but the difficulty was that writing such complex rules was very time consuming and required so much effort that very few apart from those at places like Google / Meta would ever bother doing it.

LLMs have has multiple effects on the landscape which actually make the review problem worse (more people / colleagues spitting our code with Claude etc...) whilst simultaneously making the rule making easier. As such, you can now define some pretty advanced rules about your architecture without needing insane time investment (verification of the rule working is pretty easy and very testable too).

That being said, I think that most people will initially not bother to do that many custom rules because people would need to see the value first (+ most people have a vague idea in their head, but have never articulated it), hence the default ruleset I have made.

Hopefully, this tool can be of use to the community. It is predominantly written in Rust, but python was required to allow people to take advantage of Rust's speed (and Astral's amazing work there) but without needing to learn Rust + to allow for python as an escape hatch for things not covered by the API.

Any feedback on the library would be great though! I am currently rolling it more widely at work and it's been a lifesaver so far.

[cleder]

https://github.com/repowise-dev/repowise by @RaghavChamadiya
Codebase intelligence for AI and humans: code health scores, auto-generated docs, git analytics, dead code detection, and architectural decisions via MCP.

Every file is scored 1-10 from 25 deterministic markers (McCabe complexity, brain methods, LCOM4 cohesion, god classes, native Rabin-Karp clone detection, untested hotspots, change entropy, prior-defect history and more), split into three lenses: defect risk, maintainability, and performance (static N+1 and I/O-in-loop risk traced across files through the call graph, where file-local linters found 0 of the cross-function cases repowise surfaced 557 of).

[cleder]

ARCLUX by @GSF-001
Codebase analysis tool — clone, parse, index, and visualize dependency graphs interactively. Multi-language (TypeScript, Python, Go, Java) with circular dependency detection, impact analysis, and 18 architecture detectors.

[cleder]

Correct AI-generated code can still accumulate duplicated abstractions and structural decay that tests miss. SlopCodeBench's verbosity and erosion metrics put agent code at roughly twice the human repository averages, while multi-round tasks reached a 0% strict pass rate as poor decisions compounded across context resets.
https://earendil.com/posts/measuring-code-sloppiness/

[cleder]

https://github.com/officefloor/ImpactGate by @sagenschneider
A merge gate that flags changes piling complexity onto code that is already complex, before a class quietly grows into a god class nobody can safely touch. Run it as a standalone CLI, a git pre-commit hook, or a plugin in GitHub, GitLab, and Jenkins CI.