2 ms·
I think you have to have a good balance here. I've found following a huge method or function rather complicated, but at the same time I think I find trying to
by chadcf 14y ago
I think you have to have a good balance here. I've found following a huge method or function rather complicated, but at the same time I think I find trying to track down complicated abstractions even more complicated. If you've ever stared at a new codebase trying to track down a bug, you know the joy of grepping and following chains of methods trying to get to the part that actually matters. This may not make it technically less readable but I'd say it makes it significantly less, uh, understandable?
Really, it boils down to how easy the code is to understand and maintain. Group code into logical groups. Don't break it up if the only benefit is following some arbitrary rule stating your functions should be no more than x lines long.
- rdfi 14y agoI believe the rule is not necessarily about having a small number of lines (that is just a consequence), it's about the method having one responsibility, only do one thing, and that thing should be understandable just by reading the method's name. The ultimate goal is that the code can almost be read as plain English. This has the consequence of making the methods smaller since they are narrow in scope. It's easier to understand a well named method with a few lines of code (and believe me, it's easier to properly name it than a method with a lot of code, since the former is focused in one task and it is easy to come up with a name that describes that task; and the latter, where the method does so many things that there's no way you can name it properly [have you ever found methods with names like DoWork and then 100 lines, I'd say that is a code-smell].