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

Answer 1

Personally, I lean significantly in the direction of preferring more, smaller methods, but not to the point of religiously aiming for a maximum line count. My primary criterion or goal is to keep my code DRY. The minute I have a code block which is duplicated (whether in spirit or actually by the text), even if it might be 2 or 4 lines long, I DRY up that code into a separate method. Sometimes I will do so in advance if I think there's a good chance it will be used again in the future.

On the flip side, I have also heard it argued that if your break-off method is too small, in the context of a team of developers, a teammate is likely not to know about your method, and will either write inline, or write his own small method that does the same thing. This is admittedly a bad situation.

Some also try to argue that it is more readable to keep things inline, so a reader can just read top-down, instead of having to jump around method definitions, possibly across multiple files. Personally, I think the existence of a stack trace makes this not much of an issue.

Answer 2

Some rules of thumb:

• Functions should not be longer than what can be displayed on screen
• Break functions into smaller ones if it makes the code more readable.

Answer 3

The size of the method is directly linked to its cyclomatic complexity.

The main advantages to keep the size of the method small (which means dividing a big method into several small methods) are:

• better unit testing (due to low cyclomatic complexity)
• better debugging due to a more explicit stack trace (instead of one error within one giant method)

Answer 4

As always you can say: it depends. It's more a question of naming and defining the task of a method. Every method should do one (not more) well defined task and should do them completely. The name of the method should indicate the task. If your method is named DoAandB() it may be better to have separate methods DoA() and DoB(). If you need methods like setupTask, executeTask, FinishTask, it may be useful to combine them.

Some points that indicate, that a merge of different methods may be useful:

• A method cannot be used alone, without the use of other methods.
• You have to be careful to call some dependent methods in the right order.

Some points that indicate, that a splitup of the method could be useful:

• Some lines of the existing method have clear independent task.
• Unit-testing of the big method gets problematic. If tests are easier to write for independent methods, then split the big method up.

As an explanation to the unit-test-argument: I wrote a method, that did some things including IO. The IO-part was very hard to test, so I thought about it. I came to the conclusion, that my method did 5 logical and independent steps, and only one of them involved the IO. So I split up my method into 5 smaller ones, four of them were easy to test.

Answer 5

Small methods every time.

They are self documenting (er, if well named)

They break down the problem into manageable parts - you are KeepingItSimple.

You can use OO techniques to more easily (and obviously) plug in behaviour. The large method is by definition more procedural and so less flexible.

They are unit testable. This is the killer, you simply can’t unit test some huge method that performs a load of tasks

Answer 6

I usually go for splitting functions into smaller functions that each perform a single, atomic task, but only if that function is complex enough to warrent it.

This way, I don't end up with multiple functions for simple tasks, and the functions I do extract can typically be used elsewhere as they don't try to achieve too much. This also aids unit testing as each function (as a logical, atomic action) can then be tested individually.