101–110 of 220 posts
With functional languages the mutable data is available in the reader's context. The implementation might still be mysterious but hopefully the function name is good enough to give a clue about that.
It's more of a problem with OOP language because the function call might hide a side-effect. So now the reader has to go and read the function definition to make sure no side-effect is happening in there. With functional languages the mutable data is available in the reader's context. The implementation might still be mysterious but hopefully the function name is good enough to give a clue about that.
However, it is a good point that mutability is a major problem. It's just not correct that this has anything to do with OOP.
While the example in the article isn't great for making the point I actually agree with the main idea. I understand the arguments for 'Uncle Bobifying' code but I think, as the article says, there's a balance to be struck. It's highly likely the next time I see your code (or my code if I'm coming back to it a month or two later) is when I need to fix a problem with it. While it's useful to have it split up into logic…
Agreed, although I think the example isn't too bad. I often see such "helper methods" - usually in a class called "utils" or "misc" - when (novice) programmers "try to plan ahead": how should I write this so it can be re-used? But KISS is remains a good principle. Predicting the future is hard. If in doubt, don't put in the extra indirection/abstraction. If/when the next person needs that functionality, they can refa…
Regarding the one-caller method, beloved by followers of maximum method length ideology, scorned by enemies of excessive indirection, I think we lost a very useful tool when the "structured programming" of Pascal, which prominently featured nested functions as an organisation principle disappeared. It got steamrolled by OOP name scoping (which tends to be too big for this use case) from the top while the archaic "if it exists, it is accessible" of C firmly held the lower levels. The current trend of retrofitting functional features is technically getting us back what we lost, but the use of nested functions as a simple organisational tool is still far from idiomatic. E.g. in Java>=8, when you see a lambda assigned inside a method you expect something clever functional to follow, not a simple "I put this block of code in a box to give it a name, but it won't be meaningful outside this method".
It's not indirection , it's bad abstraction that's the real issue here. Consider the example used in the article: if x.startswith("foo"): do_something_with(x) if is_foolike(x): do_something_with(x) The problem with both of these variations is that the "if-statement" doesn't have any meaning behind it. There's no gain in the indirection presented here. Whereas the following code has meaning: if checkHasPermissions(x):…
While the example in the article isn't great for making the point I actually agree with the main idea. I understand the arguments for 'Uncle Bobifying' code but I think, as the article says, there's a balance to be struck. It's highly likely the next time I see your code (or my code if I'm coming back to it a month or two later) is when I need to fix a problem with it. While it's useful to have it split up into logic…
But generally what I see in code bases is a need for cleaner code. I think real-world code suffers more from being not "clean" enough than from being too "clean". That's why I'm a bit wary of this kind of articles that can be interpreted as advocating for lower standards. It's a bit similar to articles criticizing the excess of TDD or mock-based testing. They might have a point in already mature contexts but the reality of most business software is the big ball of untested mud. We're not all DHH or Matthew Rocklin and what I see around me is a need for cleaner code and more testing, not the other way around.
Earlier quoted context omitted.
In this case the desired functionality can be encompassed in a single standard library method. However, the author of the code may have started with a much more complex implementation but still feels like `is_foolike()` is better at describing the _intention_ of the method than the eventual implementation. Replacing the descriptive method name with the actual implementation may mean the author now feels that they hav…
You know how many times I've seen that exact scenario in code bases? Plenty. Some developers just do really pointless shit and then name is terribly to add insult to injury.
It's more of a problem with OOP language because the function call might hide a side-effect. So now the reader has to go and read the function definition to make sure no side-effect is happening in there. With functional languages the mutable data is available in the reader's context. The implementation might still be mysterious but hopefully the function name is good enough to give a clue about that.
I'm just being a bit grumpy, but there are non-pure languages that aren't OOP, and there is no reason why you can't write OO code that is where all objects are immutable. However, it is a good point that mutability is a major problem. It's just not correct that this has anything to do with OOP.
The main point here is worth a broader discussion. Part of the problem is that we tend to hide behind mental concepts that a ambiguous, incomplete or just bad. DRY is a awful "thing" (a decree at best). In the worst interpretation it simply says "never write the same code twice". There is no balance or end to it. It doesn't have a competitor or alternative. It somewhat implies that it is always good. It doesn't defin…
Practically, this tends to extend the question of DRY: Is the code the same in two places, and will the code /change/ in the same way in these two places? Can we delay sharing this code to have more time to figure out if the code changes in the same way?
Maybe currently two integrations with two external applications are just the usual socket/newline separated json at the moment, so you could share the implementation. But maybe one integration gets replaced with thrift, one gets replaced with protobuf and suddenly you end up with an abstraction that's full of and that'll be ugly.