3 ms·
> If you never do that computation a second time anywhere else, I would argue that a new function is worse because you can't just scan in it quickly top to bott
by RHSeeger 1y ago
> If you never do that computation a second time anywhere else, I would argue that a new function is worse because you can't just scan in it quickly top to bottom.
I feel exactly the opposite. By moving "self contained" code out of a method, and replacing it with a call, you make it easier to see what the calling location is doing. Ie, you can have a method that says very clearly and concisely what it does... vs making the reader scan through dozens or hundreds of lines of code to understand it all.
Chapter 12 of Kent Beck's book Tidy First? is about exactly this.
- bsder 1y agoDo not cite Kent Beck as a software authority. Consider this your semi-regular reminder that Kent Beck is part of the posse (along with Ron Jeffries and Martin Fowler) responsible for the software disaster that was the "Chrysler Comprehensive Compensation System". They were also proponents of Smalltalk--which leads to object-itis and the concomitant tiny functions. As for your "function documentation", the primary difference between that assignment and a function is solely ossified arguments. And ossified function arguments is something that I would put under "premature abstraction". At some point you can pull that out into a separate function. But you should have something that causes you to do that rather than it being a default.
- RHSeeger 1y ago> Do not cite Kent Beck as a software authority. I didn't. Rather, I stated my opinion on the subject and then noted that there is a book that discusses the same (so clearly I'm not the only one that thinks this). > As for your "function documentation", the primary difference between that assignment and a function is solely ossified arguments. No, it's not. It's that the code being moved to a function allows the original location to be cleaner and more obvious.