4 ms·
It’s generally good advice. But some items do not acknowledge that there often if a trade-off to be made and the trade-off depends on the program you make. Som
by d--b 8y ago
It’s generally good advice. But some items do not acknowledge that there often if a trade-off to be made and the trade-off depends on the program you make.
Sometimes it is more readable to duplicate code or to have functions that do more than one thing. If I have a function and I need to follow four or five levels of function calls and piece things together to understand what that function does, then I can’t read the code...
- kilburn 8y agoYou can definitely go silly by splitting your functions too much. However, most times I hear this complaint, the real reason is: > 5. Naming is hard, but it's important. In other words, you should be able to understand what a function does just by the naming of the function itself. When you have a function that "calls 5 other functions" you should be able to understand what it does by just looking at the 5 function calls, without needing to go inside those child functions to check it out. The only case where this doesn't apply is when you are tracking a bug and the input/output of the function doesn't make sense. That's the only case I can think of to actually dig deeper...