3 ms·

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 i

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.

Chris_Newton 6y ago
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.
gcpwnd 6y ago
Yes context switching is a huge cognitive load. Abstractions enforce context switching.
- eyelidlessness 6y ago
  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.
- mjfisher 6y ago
  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.
IggleSniggle 6y ago
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.

Chris_Newton 6y ago

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.

gcpwnd 6y ago

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

eyelidlessness 6y ago
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.
mjfisher 6y ago
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.

IggleSniggle 6y ago

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.