Hacker News Reader

Comment by dcolkitt | Hacker News Reader

I disagree. I think the central thesis of Clean Code still holds up. You should never mix layers of abstraction in a single function.

That more than anything is what kills readability, because context switching imposes a huge cognitive load. Isolating layers of abstraction almost always means small, isolated, single-purpose functions.

View on HN

I think the central thesis of Clean Code still holds up. You should never mix layers of abstraction in a single function.

I agree up to a point, but I find this kind of separation a little… idealistic? I prefer the principle that any abstraction should hide significantly more complexity than it introduces.

At the level of system design, there probably are some clearly defined layers of abstraction. I’d agree that mixing those is rarely a good idea.

But at the level of individual functions, I have too often seen numerous small functions broken out for dogmatic reasons, even though they hid relatively little complexity. That coding style tends to result in low cohesion, and I think the cost of low cohesion in large programs is often underestimated and can easily outweigh the benefit of making any individual function marginally simpler. If you’re not careful, you end up trading a little reduction in complexity locally for a big increase in complexity globally.

Here’s some counter-argument psuedo-code:

    // v1, mixing layers of abstraction
    x = a if exists, else first()
    y = b if exists, else second()
    result = third(x,y)

    // v2, abstraction
    result = getResult(a,b)

In v1, we have the semantics of x and y, so we understand that a “result” is obtained through the acquisition of x and y. Whether we need to understand this is a judgement call. But v2 opens a different “failure to understand” modality: “getResult” is so blackboxed that the only thing it really accomplished is indirection, without improving readability.

I love Clean Code, but I think it sometimes prematurely favors naming a new function and the resultant indirection.

Yes context switching is a huge cognitive load. Abstractions enforce context switching.

The primary motivating reason to have abstractions in the first place is to prevent context switching - i.e. you shouldn't have to think about networking code while you're writing business logic.

I’d say that’s a sign that either it’s the wrong abstraction, there’s implicit coupling (a distinct variant of the wrong abstraction), or both sides of the abstraction are in so much flux that the context switching is inevitable until one or both layers settle down.

Reply on news.ycombinator.com