Jesper de Jong wrote:It's a good idea to write methods that are not too long, and especially write methods that have only a single purpose (one hint for this is: if you have a hard time deciding what the name of a method should be, then the method is probably doing too many things).
But you can also go too far - as you can see, your version with four separate one-line methods is a lot longer than one method with four lines. Especially if you're not going to re-use those four one-line methods in other methods, then there's not much of a benefit to have these four methods.
This is of course something for which there are no hard rules, but my rule of thumb would be: if a method becomes longer than about 20 lines, think about how you could design it in a different way or split it up into smaller, more clear methods.
I share your concern about making the code longer which is why I asked the question, but when I look at examples in the Clean Code book they seem to do this a lot for clarity. For example part of the cleaned up version of the SetupTeardownIncluder on pg 50 looks like this:
Similar to my original example, it has several one line methods and could be shortened by making the following changes.
I assume the author would claim the first while longer was easier to follow.
I appreciate your response and am not trying to argue with you. I just wanted to get some feedback on how other programmers decided when they were going too far in shortening their methods. Thanks!