Comment by richardbarosky | Hacker News Reader

Comment by richardbarosky | Hacker News Reader

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.

This talk.

What We Know We Don’t Know • Hillel Wayne. (2019, April 28). Hillel Wayne. https://www.hillelwayne.com/talks/what-we-know-we-dont-know/

>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.

> it doesn't account for the control flow indirection that happens through OO method dispatch itself

Every indirect call is a conditional branch, where the condition can be arbitrarily far away in time and space.

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.

I suspect that we could bring this measure into the modern world with a little help from either DFS or ai.

Something like abstractions traversed during interpretation, lines of abstraction v.s. functional implementation, or logic statement dispersion.

It was hard to pin down what was abstraction vs. implementation, but it's much easier now.

The thing is, AI has no idea when an abstraction is good or not.

The reductio ad absurdum here is that, if abstraction can just be assumed to be bad for quality and maintainability, then perhaps we should go back to hand writing machine code for non-microcoded sequential execution CPU architectures. Conversely, if that idea sounds as preposterous to you as it does to me, then you’re stuck conceding that at least some abstractions are mostly good. So then, before you can automate deciding which ones should and should not count against a code quality metric that’s computed automatically, you need to find an operational definition that can be applied deterministically.

Reply on news.ycombinator.com