Tuesday, August 31, 2010

Large functions are evil

Yes, there I said it. In any code base, there is a tendency for some functions to become do-all functions, spreading over pages and pages, defying all object orientedness and principles modularity. Why does this happen? I have a principle that no function should be longer than 1-2 pages.

As soon as a function grows larger than that, it reaches a critical mass, and becomes a black hole, into which everything is thrown. The bigger function is, the harder it is to understand it, and as a result, anyone looking at it, will be too scared to split it up and make it nice for the next person. That's because the splitter-upper runs the risk of breaking existing functionality.

The larger the function, the more dependencies there will be between parts of the function and the variables declares at various points in the function. Various ifs and for loops have their counters, and unless you know what all of them are doing, you could create problems by doing things your way. Large functions become more and more scary, and they grow more and more. Each new developer looking at the function sighs or posts it to the DailyWTF.com, but is still too scared too touch it. Everyone knows this function is up for refactoring, but noone takes the time to do it, and the monster continues to live.

The important thing to do here, is take the time and break up this function as soon as it becomes just a tad bit too large. In the extreme cases there may be a need for another class, but most of the time it's enough to just split it up into 2-3 functions, whose purpose is clear.

The immediate benefit is that at any given point a developer needs to only consider the logic of one of the functions. Also, the relationship between these functions is defined more clearly thru function signatures (instead of the implicit relationships between parts of the large function). Most importantly the scope of any given variable will now be shorter, so the side-effects and unintended consequences of each variable are limited.

So, ladies and gentlemen, the moral of the story is - refactor large functions early, before they turn into black holes!