Best practices: Many small functions/methods, or bigger functions with logical process components inline? [closed]

Answer 1

I find that having many small methods makes code easier to read, maintain and debug.

When I'm reading through a unit that implements some business logic, I can better follow the flow if I see a series of method calls that describe the process. If I care about how the method is implemented, I can go look in the code.

It feels like more work but it ultimately saves time.

There is an art, I think, to knowing what to encapsulate. Everyone has some slight difference of opinion. If I could put it in words I'd say that each method should do one thing that can be described as a complete task.

Answer 2

Something I learnt from The Code Complete book:

• Write methods/functions so that it implement one chunk(or unit or task) of logic. If that requires breakdown into sub tasks, then write a seperate method/function for them and call them.
• If I find that the method/function name is getting long then I try to examine the method to see it it can be broken down into two methods.

Hope this helps

Answer 3

I make each function do one thing, and one thing only, and I try not to nest too many levels of logic. Once you start breaking your code down into well named functions, it becomes a lot easier to read, and practically self-documenting.

Answer 4

The bigger the method, the harder to test and maintain. I find its much easier to understand how a large process works when its broken down into atomic steps. Also, doing this is a great first step to make your classes extensible. You can mark those individual steps as virtual (for inheritance), or move them into other objects (composition), making your application's behavior easier to customize.

Answer 5

It depends a bit ... on mindset. Still, this is not an opinionated question.

The answer rather actually depends on the language context.

In a Java/C#/C++ world, where people are following the "Clean Code" school, as preached by Robert Martin, then: many small methods are the way to go.

A method has a clear name, and does one thing. One level of nesting, that's it. That limits its length to 3, 5, max 10 lines.

And honestly: I find this way of coding absolutely superior to any other "style".

The only downside of this approach is that you end up with many small methods, so ordering within a file/class can become an issue. But the answer to that is to use a decent IDE that allows to easily navigate forth and back.

So, the only "legit" reason to use the "all stuff goes into one method/function" is when your whole team works like that, and prefers that style. Or when you can't use decent tooling (but then navigating that big ugly function won't work either).

Answer 6

I always break long methods up into logical chunks and try to make smaller methods out of them. I don't normally turn a few lines into a separate method until I need it in two different places, but sometimes I do just to help readability, or if I want to test it in isolation.

Fowler's Refactoring is all about this topic, and I highly recommend it.

Here's a handy rule of thumb that I use from Refactoring. If a section of code has a comment that I could re-word into a method name, pull it out and make it a method.