More than a decade ago, a tool called the CRAP metric entered the software development lexicon. Its full name, Change Risk Analysis Prediction, was less memorable than its acronym. But the idea it promoted, that complex code is risky code, has not faded. Developers today still encounter the CRAP threshold in continuous integration pipelines, code review tools and technical debt assessments.

What You Need to Know

The CRAP metric blends cyclomatic complexity and code coverage to flag methods that are both complex and poorly tested. It was introduced by Alberto Savoia in a 2011 blog post titled “This Code Is CRAP.” The metric sets a threshold above which a method is considered at high risk for defects. Many static analysis tools still support CRAP calculations today.

The Origin of “This Code Is CRAP”

The phrase “This Code Is CRAP” originated as a blog post title in 2011 from Google software engineer Alberto Savoia. He proposed a simple quantitative approach for identifying code that is likely to contain bugs. The metric combined two existing measures: cyclomatic complexity, which counts the number of independent paths through a function, and code coverage, which measures how much of that code is exercised by automated tests.

Savoia argued that a method with high complexity and low coverage is a breeding ground for errors. He defined a formula that produced a CRAP score. A score above 30 was considered dangerous. Teams could use this number to prioritize refactoring or additional testing.

The idea gained traction because it was easy to understand and automate. Developers could run a CRAP analysis as part of their build process. Tools like SonarQube, CodeClimate and various IDE plugins adopted the metric. The acronym itself made the concept stick.

How the CRAP Metric Works

The CRAP calculation depends on two core inputs. The formula itself is straightforward but its implementation requires accurate measurement of both complexity and coverage.

  • Cyclomatic complexity: Measures the number of linearly independent paths through a function. Higher values indicate more branching and harder-to-test code.
  • Code coverage: The percentage of lines or branches executed during automated tests. Lower coverage means more untested paths.

The CRAP score increases exponentially as complexity rises and coverage drops. A method with a complexity of 10 and 90 percent coverage may pass. The same complexity with 50 percent coverage will likely fail. The threshold of 30 is not arbitrary. Savoia selected it after analyzing real projects.

Why This Matters

The CRAP metric remains relevant because it addresses a persistent problem. Software teams write code quickly and test it incompletely. The result is technical debt that slows future development and increases bug rates. CRAP provides a concrete, automated signal to intervene.

For individual developers, a high CRAP score means their code is fragile. Changes in one area often break unrelated features. For engineering teams, an overall CRAP trend indicates whether the codebase is improving or decaying. Continuous integration systems can reject pull requests that increase the CRAP score beyond a defined limit.

The metric is not without criticism. It oversimplifies risk by ignoring factors such as dependencies, developer experience and domain complexity. Some teams disable it because it generates too many false positives. Yet the core insight, that complex untested code is dangerous, has shaped modern quality enforcement. Static analysis tools, linters and code review standards all reflect this principle.

The legacy of “This Code Is CRAP” extends beyond its acronym. It popularized the idea that code quality can be measured and gated automatically. Today that philosophy is standard practice in DevOps cultures. The metric itself may not be perfect but the problem it identified remains central to software engineering.

What You Need to Know

What You Need to Know

The CRAP metric was introduced in 2011 and remains in use today. It flags methods that are complex and insufficiently tested. Teams can integrate CRAP scores into their development workflows to catch risky code early. While not a perfect measure, it provides a useful starting point for code quality discussions.