Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: