Hacker News Reader

Comment by morbidhawk | Hacker News Reader

I started reading the "Real-World Maintainable Software" book and found questionable advice given in the very first section of the book:

> 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

View on HN

It's about eliminating cognitive load when reading and/or modifying source later. The more code you can eliminate from what is being looked at, the easier it is for the reader to understand the purpose of the function and what it is accomplishing.

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.

> it is easier to 'surgically' modify a single method that does one simple thing, than adjust one tiny piece of a much larger 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

Reply on news.ycombinator.com