This Code Is CRAP (2011)

Title is editorialized. Original: "This code is CRAP" referring to code in review as Change Risk Anti Pattern.

Also, (2011)

I'm sure this method has evolved and/or been supplanted over the last 15 years, but one thing that struck me reading this is how much the dynamics of unit test coverage have changed in recent history, with AI-generated commits containing 10x as many unit tests (many of them kind of silly and tautological) as in the olden days. Gonna need to update some of those coefficients in their CRAP1 formula... Or maybe test coverage has/will become too noisy a parameter to use at all.

When a measurement becomes a target, it ceases to be a good measure.

Wait, I thought all hand-curated enterprise code was godly pre-LLMs?

A measure is only good if I take action on it and in turn make things better. There are a lot of things that are easy to measure, but there is no useful action I should take on the measure.

I've seen a couple of tools to calculate the CRAP score. I haven't used them in anger though.

For Rust there's https://crates.io/crates/cargo-crap, and for Go there's https://padiazg.github.io/go-crap/

I have a goal to make the codebase at work cargo-crap compliant and enforce it with CI. I let an agent run overnight with it once and the diff touched like 40% of our codebase which is untenable for a single merge. So for now I’m doing it piecemeal as the opportunity presents itself.

The pendulum has swung too far in the direction of class, function, cyclomatic complexity (and here, CRAP) and similar idiotic metrics.

This reminds me of a talk Sandi Metz did called "All the Little Things" where she covers the Gilded Rose kata. In the talk, she reworks her solution until there's almost nothing left showing the essence of the problem being solved.

The cyclomatic complexity metric is touted at each step as a proxy for goodness of design and removal of complexity. However, a weakness of the measure itself is that it doesn't account for the control flow indirection that happens through OO method dispatch itself.

At the same time, Kevlin Henney's talk called "Gilding the Rose" takes the same kata and arrives at a far more sane solution he works up to and reveals at the end.

Short functions used to be hot. Uncle Bob used to proselytize "The first rule of functions is that they should be short. The second rule of functions is that they should be shorter than that." Now emphasizing the benefits of longer functions is pretty trendy. https://github.com/johnousterhout/aposd-vs-clean-code

This industry is pretty idiotic sometimes ¯\_(ツ)_/¯

(2011)

>Note: This post is rated PG-13 for use of a mild expletive. If you are likely to be offended by the repeated use a word commonly heard in elementary school playgrounds, please don’t read any further.

Mild as this ironic passive aggressiveness is, can't imagine something like this in modern sterile corporate messaging.

Every time I see a software update I cringe inside.

> CRAP1(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m)

and

> Here’s why we think that CRAP1 is a good anti-pattern to detect. Writing automated tests (e.g., using JUnit) for complex and convoluted code is particularly challenging, so crappy code usually comes with few, if any, automated tests.

This is so wrong.

The formula uses code coverage as a fundamental metric, when in reality, a lot of people write code "correct from construction", so coverage is not even applicable. Many times too, people only care the use cases they care about work perfectly.

There are also many other reasons code is not tested, not because it's complex, but because it's simple.

Google is crap

Are we just writing tautologies now?

(2011)