How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
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.
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.
>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.
Small correction: IIRC Google never fully dropped it. In 2018 they pulled "Don't be evil" from the top of the code of conduct, but it's still the last line. Alphabet's own motto became "Do the right thing." Whether anyone acts on either is another matter.
The metric came out of Alberto Savoia's crap4j around 2007. Engineering blogs back then were written by engineers and posted, not routed through comms. Sun and Microsoft bloggers got away with far worse. Now every post gets a review pass and the jokes die in it.
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 ¯\_(ツ)_/¯
A while back Hillel Wayne did a talk (whose name I forget) on what empirical evidence on software quality actually says.
As I recall, he concluded that there’s really no support for then-popular ideas like short functions, reducing cyclomatic complexity, avoiding explicit branch statements and loops, or TDD. (Tests yes, just not TDD.)
He made a pretty strong case that only two principles are particularly robust. One was that limiting code volume is good. The other is that working people too hard is bad.
>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
Amen, it’s hard to push back against an opaque term (cyclomatic!) when it isn’t really a measure of goodness, it’s a measure of branching, kind of a normal thing in code.
Early on I found that code with low cyclomatic complexity was just usually extremely verbose, lots of passing this to that while avoiding the branching necessary to get something done.
And yes, you can game the metric by hiding the complexity among the confusion of objects and components.
Oh god, yes. The powers that be in my workplace are obsessed with cyclomatic complexity, so now we’re reviewing a flood of LLM diffs that take perfectly good code and extract each loop into its own function with a dozen arguments. The code is now more maintainable on paper and far, far less maintainable (by a human) in practice.
Reasonable cyclomatic complexity is useful (at least) for testability. No metric is perfect and no metric should be a primary goal, but it has its use, and if you read e.g. a bit of leaked Windows you certainly will understand why it matters (and not because it has a particularly low cyclomatic complexity...)
Of course if you introduce new methods of dispatch and do not take them into account into a metric, you end up with something less... precise? useful? But given the primary intent and why and how the metric was created this seems a pretty trivial observation.
Now I agree it is also retarded to attempt to get only very short functions or extremely low cyclomatic complexity everywhere (even if you try to adapt it to count new kind of dispatch), because the only effect that produce is that it moves the complexity in another more abstract place we are less well equipped to manage.
"Short functions used to be hot. Uncle Bob [...]": well yes, Internet and sometimes group of people inspired ultimately by Internet and group effects can be pretty idiotic, but honestly Uncle Bob ideology was never considered serious in actual studies, and it is now even widely recognized mostly bullshit. It is just a kind of tech influencer if you want. Computer science and/or software engineering has more serious branches, where cyclomatic complexity can have its use.
Wow! Did not expect this blast from the past this morning. I worked with Alberto and Bob at the same startup long ago. Hello to any other Agitators who found this today.
> 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.
Fwiw it's not a tautology, CRAP is an actual metric: cyclomatic complexity combined with test coverage. We ran crap4j-style reports on a legacy Java codebase once and the top ten offenders were always the same few god-classes. Fixing those first beat any broad cleanup effort we tried.
Plausible, though as far as I know the normalizer's rules aren't documented anywhere, so that's inference from observed behavior. Either way the loss hurts: without This, the title reads like a verdict on the article instead of a pun on the CRAP metric it's about.
Has anyone actually checked that CRAP predicts bugs better than plain cyclomatic complexity does? Coverage only says a line ran, not that anything asserted on it. A 100% covered function with zero assertions scores perfectly. Seems like the formula rewards hitting the metric, not writing good tests.
