4 ms·

God do I hate it when a function is broken down into sub functions that are only called once for the sake of readability. And then these sub functions themselve

God do I hate it when a function is broken down into sub functions that are only called once for the sake of readability. And then these sub functions themselves are broken down too until you have Bob Martins magical 5 to 10 line functions. On the surface that looks like clarity, but when do you have to look at that code? Often when you need to fix an issue or extend a functionality. You need to understand what's going on in detail. When you debug a workflow or Algorithm in a code base like this you have to jump from one function to the next and suddenly you are 6 layers deep and totally lost the context. It is so much harder to grasp code structured like this compared to simple linear flows where each step is marked by inline comments.

rileymat2 6y ago
As a counter example, I was able to customize FitNesse for my needs quickly and easily. I can't remember the exact reason (it was about 8 years ago), but the change was simply adding a new class inherited from a base and using that. I did not have to change legacy code (except at the instantiation site) to do it. This was in Java which is not even my primary language. It was pretty impressive. It breaks down to basically, when you can keep the whole system in your head, that style is needlessly complex, but once it exceeds that level, then it is better.
rualca 6y ago
I disagree. I find that breaking functions into subfunctions extremely helpful to make code easier to read and understand and follow, and consequently to track and fix bugs. Extracting functions does way more than removing descriptive comments. When you extract a function, you're compartmentalizing code and adding scopes where none existed and limit contexts. When you extract a function, you're explicitly constraining a block to comply with a contract, which allows you to not care what goes below that point. You just care about pre and post-conditions, and that is more than enough to troubleshoot and fix bugs, and more importantly not add them.
UncleMeat 6y ago
This depends. If a subcomponent only requires a small subset of the data used by a function and its input/output can be modeled well by a single simple data instance, then this often helps. This goes wrong when the subcomponents aren't actually logically distinct and you end up passing basically all of the local variables between each one.

rileymat2 6y ago

As a counter example, I was able to customize FitNesse for my needs quickly and easily. I can't remember the exact reason (it was about 8 years ago), but the change was simply adding a new class inherited from a base and using that. I did not have to change legacy code (except at the instantiation site) to do it. This was in Java which is not even my primary language. It was pretty impressive. It breaks down to basically, when you can keep the whole system in your head, that style is needlessly complex, but once it exceeds that level, then it is better.

rualca 6y ago

I disagree. I find that breaking functions into subfunctions extremely helpful to make code easier to read and understand and follow, and consequently to track and fix bugs. Extracting functions does way more than removing descriptive comments. When you extract a function, you're compartmentalizing code and adding scopes where none existed and limit contexts. When you extract a function, you're explicitly constraining a block to comply with a contract, which allows you to not care what goes below that point. You just care about pre and post-conditions, and that is more than enough to troubleshoot and fix bugs, and more importantly not add them.

UncleMeat 6y ago

This depends. If a subcomponent only requires a small subset of the data used by a function and its input/output can be modeled well by a single simple data instance, then this often helps. This goes wrong when the subcomponents aren't actually logically distinct and you end up passing basically all of the local variables between each one.