O'Reilly Gives Away Free Programming Ebooks
oreilly.com
oreilly.com
> The first guideline indicates that our methods should be short, usually no more than 15 lines of code
Why would that be a good reason to break apart code into different methods? 15 lines isn't even that big
> We can reduce the number of branching points per unit by moving the validation logic to its own method
Before I follow this advice I'd like to know why branching points per method unit is worse than total number of method branches. This wasn't explained to me and I don't see any reason why it should be a guideline worth following
At some point, someone is going to need to change your code. When that happens, it is easier to 'surgically' modify a single method that does one simple thing, than adjust one tiny piece of a much larger function. Even though the change might be exactly the same, it will be easier to understand which callers are affected by the change so you can detect the impact of your modification.
It is a guideline, not a rule. You'll (probably frequently) have methods that logically make sense to keep longer, but if you're writing and find yourself creeping past that, it is a good indicator you might want to review the function and make sure you're not inlining something that might make sense as its own function.
I would agree for the most part but modifying one small function might cause unwanted side-effects when that function is reused elsewhere (tooling that reports references can help this). A good descriptive function name could help as well. When a function is not meant to be used in multiple places another option is writing a nested function, there might be arguments against that but that helps keep the number of possible method branchings to a better minimum