3 ms·
Refactoring a larger function into a group of small ones doesn't come for free. Even though it might often be a good idea, when it's not done with care it can c
by yowlingcat 6y ago
Refactoring a larger function into a group of small ones doesn't come for free. Even though it might often be a good idea, when it's not done with care it can confuse, not clarify. It comes down to a matter of judgment of the whole and deliberate expression. That's contextual, not absolute.
With that said, I somewhat agree with the spirit of what you are saying. I tend to lean in the direction of smaller methods when possible because they often make things more readable and more explicit.
- datavirtue 6y agoIf it isn't clear it's not easy to change, making it "bad code." Do what needs to be done to make the intent of a block of code super clear, in plain English. Comments don't count, as illustrated clearly in The Pragmatic Programmer, for instance.
- yowlingcat 6y agoAs much as I like this idea in theory, in practice, a lot of the hairiness and opacity of code I've seen comes from the business domain itself, not the code. There is only so pretty you can make code which has to do painful and unintuitive tax calculation, or credit underwriting logic. But often times, this code is the most critical to the business as a whole. It is code which is counterintuitive because it reflects a reality which is itself painful and unintuitive. When it comes to writing clear code in reality, I'll repeat what I said before -- there aren't absolute rules, and things are contextual. Where it's possible, it's absolutely ideal to keep things compact and expressive. But that only will take you so far. When you run into domain logic that is to an extent incompressible, trying to compress things further will only impede clarity.