31–40 of 121 posts
Aside from the clickbait-y title, I find it quite disturbing to base that whole piece on, what even the author describes as, problems in "codebases inherited from folks who’d internalized this idea to such an unholy extent". Indeed, small functions can be bad if you completely and utterly overdo it. But wait, that's true of nearly everything else.
So, the author thinks this is harmfull?: var area= ( width, height ) => width * height; If not, it is just clickbait for me.
It would be harmful if you were calculating something subject to change, like, say price.
price = (cost) => cost * 1.10;
function decimal Price(cost) { .. }
Even your example it could be dangerous:
var area= ( width, height ) => width * height;
var area= ( width, height ) => (width + 1.0) * (height + 1.0);
Obsessive decomposition of the sort Fowler, for example, is cited preferring, very quickly becomes pathological - I suspect that the codebase Fowler describes in that tweet, to the developer as yet unfamiliar with it, reads like one of those old IBM field engineer manuals where a giant circuit diagram is spread across 800 letter-size pages, all bordered with dozens of numbered arrows each referencing the page on whic…
But if the stuff that needs to change is abstracted, it only has to change in one place. IMO, the point of "prefer duplication over the wrong abstraction" is that "all the stuff that needs to change" is a partially-to-totally unknown quantity. You can either guess at the time you have the minimum possible amount of knowledge (when the code is initially written) or wait and make that decision later with more evidence.…
A()
B()
C()
// Step A:
... 3 lines
// Step B:
... 4 lines
// Step C:
... 3 lines
A better example of 3 functions is when you have
y = A(B(x))
y = A(B(C(x)))
Seriously, HN should have code that auto flags anything including a subject line of "considered harmful".
where X is any number of lines necessary for implementing the ONE thing that function should be doing
Any attempt to replace X with a concrete number will invariably sacrifice simplicity for the sake of that number.
Earlier quoted context omitted.
Clean Code can be harmful? Or the person dogmatically applying the advice? Martin warns against such blind dogmatism. He even goes so far as to explain the thought process behind most of his recommendations so that one may consider whether the rule applies or not. On balance, Clean Code does far more good than it does bad. I have yet to see these dogmatic Clean Coders blindly applying Martin's advice. Not in industry…
> I have yet to see these dogmatic Clean Coders blindly applying Martin's advice. You're lucky. I've seen it plenty of time. In one extreme case we even had to let go a perfectly (formerly) competent dev after he read that book and went crazy (yeah, seriously).
Doubly so if it was on Coding Horror.
> an awful lot of times, pragmatism and reason is sacrificed at the altar of a dogmatic subscription to DRY, especially by programmers of the Rails persuasion.
I'm not making this a tribal thing but it does sometimes feel like there's a cultural tendency in the Ruby and Javascript communities to... well... preach a little bit. All advice is flawed and most maxims are only partially true.
If a community bounces from one "one true way" to another all the time then it's probably not a particularly healthy environment for those who are learning - as they tend to lack the experience to put advice into the correct context.