Deterministic slop analysis
Measures how sloppy a codebase is, and shows its working. Every point of every score traces back to a rule you can read, disable, and reweight.
Reading, this repository
The tool grades itself. A slop analyzer with sloppy source has no standing to report on anyone else's.
The name invites that assumption, so it is worth answering first. slopometer never asserts, estimates, or scores who or what wrote a line, and a test in the suite enforces that no message, category, or output field can.
One of its five rule families does look for patterns common in code that was generated and never edited afterwards: comments narrating every statement, documentation templated across a dozen items, checks that cannot fail, placeholder bodies left in place. Those are worth finding because of what they are, not because of where they came from. Plenty of hand-written code has them. The family is called filler for exactly that reason.
Five families, forty-six rules
rust finds error handling that panics instead of propagating, abstractions with no second user, items exposed more widely than their use requires, and functions and files past the size you set.
typescript finds interfaces with a single unexported implementor, aliases that only rename, types whose properties are almost all optional, modules that exist only to forward, shapes declared twice under different names, and the constructs that discard checking: written any, non-null assertions, casts laundered through unknown, suppressions with no reason, console calls in a library, and default exports.
c finds functions given more linkage than anything uses, bodies placed in headers, headers nothing includes, declarations nothing defines, and mutable state at file scope. Nothing is preprocessed, which costs more than it sounds.
doc finds public API with no documentation, documentation that only restates the signature, documentation that has drifted from the code beneath it, comments that paraphrase the line below, and unresolved work markers.
filler finds the patterns above.
Deliberately absent: anything needing type inference or borrow analysis. Proving a clone unnecessary requires the borrow checker, so that job belongs to clippy, which has one. A rule that cannot establish what it needs is not shipped half-working.
It never compiles your code. Compiling runs build scripts and procedural macros, which is not an acceptable thing to do to a repository you did not write. Everything comes from parsing source and reading manifests.
It never reaches the network. Two runs over unchanged input produce byte-identical reports. Results do not vary with the time, the machine, or the user.
It never hides its reasoning. Every point of every score decomposes into findings you can open, and --explain prints the arithmetic behind each one.