This Code Is CRAP (2011)
summary
The CRAP (Change Risk Anti-Patterns) metric provides a way to quantitatively identify risky code by combining cyclomatic complexity and test coverage. It assumes that complex code with low test coverage is more likely to be problematic and harder to maintain. By using an empirical formula, developers can move from subjective complaints about 'crap' code to an objective score. This allows teams to prioritize which parts of their codebase require urgent refactoring or additional testing.
key points
- The CRAP1 formula calculates a score based on the square of cyclomatic complexity and the cube of the lack of test coverage, flagging methods with a score over 30 as risky. This specific mathematical curve was developed empirically by comparing the formula's results with subjective expert evaluations of various Java projects.
- High complexity combined with low coverage is a strong indicator of poor design because complex logic is harder to test, and a lack of tests often suggests the author lacked the time or care to ensure correctness. While the metric is not perfect and can ignore cohesion or coupling, it serves as a useful first pass for identifying technical debt.
- The metric has been widely adopted and ported to numerous languages including .NET, Ruby, and PHP, moving beyond its original Java implementation. This broad adoption demonstrates a general industry need for tools that can highlight dangerous code areas without requiring manual auditing of every method.
who should read it
Software developers and quality assurance engineers who want a data-driven way to identify high-risk areas of their code. It is particularly useful for those working in Agile environments who prioritize iterative improvement and refactoring.
discussion skeptical
consensus
Commenters generally agree that code coverage and cyclomatic complexity are flawed metrics that are easily gamed, especially through the use of AI-generated tests and refactoring. They argue that pursuing these metrics often leads to 'Goodhart's Law' in action, where the focus on the metric overrides actual software quality and behavior coverage. There is a shared sentiment that while some constraints are useful, strict adherence to these measures often results in more verbose, less maintainable code.
top insight
The discussion highlights that the industry's obsession with short functions and low cyclomatic complexity often merely displaces complexity into object-oriented dispatch or fragmented abstractions rather than removing it. This shift makes code 'maintainable on paper' while becoming significantly harder for humans to reason about in practice. The mention of Hillel Wayne's research suggests that only limiting total code volume and avoiding developer burnout are truly robust quality principles.
Generated by an LLM from the article and thread. Check the sources before relying on it.