Since I started developing software (a long time ago) I see people talking about ways to evaluate when a function or method is too big. I bought all these shapes up to one day. This is normal, this is what inexperienced and yet naive developers do. But one day I discovered that there is no magic solution and especially that there is no magic number.
As far as I know there are no reliable studies that indicate the ideal size of a function. Any attempt to find something like this seems doomed to failure. We can observe what other people think of this, take advantage of their experiences and try to facilitate a path for each individual case to be more easily determined.
In general presented problems generic answers do not help much and specific answers just try to sell as general something that does not apply to the specific case. And many well-known books do this. They need to satisfy the readers' desire for some magic formula.
In the '80s I heard the programmer was going to finish. There would be formulas that determined everything as a program could behave and anyone would put into the computer what they needed and the program would be finished. There are doctoral theses on this! Today everyone knows how ridiculous this is. The programmer will always be needed precisely to determine case by case what is good or not, what solves or not a problem. You can’t generalize. AI will help you encode better, but not model.
When someone tries to explain how to make the right decision you can say what you need to do to facilitate the process but nothing that can be advised will make someone make the right decision.
Some definitions and tips
Let’s see some attempts in English that occurred in Software Engineering.SE to reach a "definitive conclusion".
What should be the Maximum length of a Function? The question was closed because you can’t answer this without resorting to opinions and we even found a joke about it in comment from Thomasx. Does anyone doubt it’s a joke?
When someone posts a number of lines a function should have the person must be making fun.
But there are answers there that help us understand how to know the ideal size of each function individually. There is even the presentation of study that shows the difficulties of people to understand problems and explanations. Much information, dispersed. Little information, no help, or worse, help the wrong way.
Some say depends on of the language being used. Of course it depends. It also depends on the technology used, the problem being solved, the requirements, the team that is working on the problem and probably other things.
Others say the function should be as little as possible. And it seems to be good advice. The problem is knowing what is as small as possible. Often this is interpreted as the least amount of lines possible. People tend to have an incredible tendency to take certain recommendations literally. And worse, to think they’re worth anything. From this comes such "good practices" and suddenly you can no longer do otherwise, more correct, because it hurts the "good practice".
There is even the statement that you should decrease what the function does until it is no longer possible to decrease. A teacher has already told me to do this. I gave him a code on Pascal worse than Assembly. Exaggerating a little each function did just what an Assembly instruction is able to do.
Other good advice: If you don’t know how to give a good name to the function, it probably does more than it should. You’re on the right track, a function cannot do more than it should. But it still doesn’t make it clear what this is.
Someone asks what the ideal size of a building is. Why do not all buildings of the same size?
Here comes the problem of cyclomatic complexity. It’s really relevant. It’s something that really gets in the way of understanding codes. One of the reasons we divide the functions into smaller parts is precisely to facilitate the understanding of code. This tends to facilitate maintenance as well. There is no fixed number of what is a problem. There are studies indicating that this is important and that there is a relationship between it and the amount of defects in software. And large functions tend to have more cyclomatic complexity.
There are answers making it clear that a function should do only one thing. There seems to be no discussion about this. It is possible but unlikely that a function with sole responsibility has many tens or hundreds of lines. All experienced developers know that most functions will have very few lines. But it is also clear that divide too much, just because someone said that the functions should be small, do not bring good results. Over-segmenting can make code harder to track. You get out of the code spaghetti for the lasagna code.
Hence the question arises whether we should create a function for something that will not be used again elsewhere. By the principle of the sole responsibility of the function, yes, we must. But we must not exaggerate. You have to evaluate the case so that you don’t make it harder to understand what you’re doing, create a more complicated situation to deal with, make performance unacceptable or make it harder to maintain in the future.
So if it is something repeated, should it be put into function? Not necessarily. It is likely but, again, it depends on the case. Remembering that DRY does not necessarily mean deleting code repetition. And even if it is a case that is ideal by DRY, there are other factors that need to be taken into account. Anyway repetition of code can be one cause a function to be large. Repetition is a problem in itself. I’ve seen cases that repetition makes the code smaller. That’s why compilers tend to optimize code better than humans. They evaluate the specific case objectively and know for sure what will be more or less fast. They make no assumptions.
There are good observations that size can affect performance for more or less. This was even the original concern of the questioner, but it was not clear to anyone. Calling a function has cost, calling more than it should (because it has more functions than it should, by dividing more than it should), affects performance negatively, including forcing unnecessary memory manipulation. Large functions can affect the cache or can complicate a Jitter and the organization of memory. But large functions usually affect negatively more by a side effect. Since it can be more complex than it should be, it can be easier to make mistakes that affect performance. The opposite is also true. Large classes or modules, full of methods or chopped functions can cause the same effect. I speak of this with more property in more specific question on resource consumption.
I like the phrase that a function must have the size it needs to have. Yes, that doesn’t mean anything, but it’s the only undisputed truth.
Some people talk about functions that deal with huge switch
s. For those who limit the number of lines they probably have an exception to this. How many other exceptions are made? What if all this was unnecessary? Does the exception let it go anyway? It seems that looking at the number of lines is at least looking at the wrong problem.
And note that each one gives his own interpretation of what he has read somewhere. And it can’t be very different. Each has a unique past path, works in unique situations.
Then I found a question closed as well. It is getting long, I will not extend. It is said a lot that lines is not a good parameter and the function should do just one thing. Some say large functions are difficult to test. This is true but complicate a design just to facilitate the test also does not seem to me one of the best ideas (and there are holy wars on this).
And finally in that question shows how setting boundaries makes no sense.
If you look at the books Clean Code and Code Complete will see a huge discrepancy between the recommendation of the ideal number of lines. What shows that these books should have their credibility questioned (not that the whole book is bad) since they show that these numbers are just meaningless opinions. But if you want to hear some say to you a number, in which believe? 20 of Clean Code or 200 of Code Complete? Or 2 or 12 that someone else might say?
In that reply i talk about some things that are most important to maintain a "clean function".
Completion
If you want to know the number of lines a function should have to draw the programmer’s attention to determine if it is large, choose the number one. A line may already be doing more than it should. And that’s the important thing. Unless you have a reason to do the opposite, choose the size that best organizes the purpose. Don’t do any bigger or smaller than this.
Related question: http://answall.com/questions/31485/o-tamanho-de-uma-fun%C3%A7%C3%a3o-afeta-a-performance-e-consumo-de-mem%C3%b3ria
– bfavaretto
Bad practice is not in the number of lines but in the amount of responsibilities; each function should have a single responsibility. The number of lines is only a warning that the method may have too many responsibilities, which could be moved to other functions. One of the main reasons it’s bad practice is that our brain has a limit of things it can focus on at once. When we look at a block of code we are usually interested in only one of its functions, so the other functions that are there take our focus, making the work difficult.
– Caffé