Why are some functions extremely long? (ideas need

Question

I am writing a small academic research project about extremely long functions. Obviously, I am not looking for examples for bad programming, but for examples of 100, 200 and 600 lines long functions which makes sense.

I will be investigating the Linux kernel source using a script written for a Master's degree written in the Hebrew University, which measures different parameters like number of lines of code, function complexity (measured by MCC) and other goodies. By the way, It's a neat study about code analysis, and a recommended reading material.

I am interested if you can think of any good reason why any function should be exceptionally long? I'll be looking into C, but examples and arguments from any language would be of great use.

Answer 1

The only ones I've recently coded are where it doesn't achieve much to make them smaller or can make the code less readable. The notion that a function that is over a certain length is somehow intrinsically bad is simply blind dogma. Like any blindly applied dogma ot relieves the follower of the need to actually think about what applies in any given case...

Recent examples...

Parsing, and validating a config file with simple name=value structure into an array, converting each value as I find it, this is one massive switch statement, one case per config option. Why? I could have split into lots of calls to 5/6 line trivial functions. That would add about 20 private members to my class. None of them are reused anywhere else. Factoring it into smaller chunks just didn't add enough value to be worth it, so it's been the same ever since the prototype. If I want another option, add another case.

Another case is the client and server communication code in the same app, and its client. Lots of calls to read/write any of which can fail, in which case I bail and return false. So this function is basically linear, and has bail points (if failed, return) after almost every call. Again, nothing to gain by making it smaller and no way to really make it any smaller.

I should also add that most of my functions are a couple of "screenfuls" and I strive in more complex areas to keep it to one "screenful", simply because I can look at the whole function at once. It's ok for functions that are basically linear in nature and don't have lots of complex looping or conditions going on so the flow is simple. As a final note I prefer to apply cost-benefit reasoning when deciding which code to refactor, and prioritise accordingly. Helps avoid the perpetually half-finished project.

Answer 2

Read the chapter in McConnell's Code Complete about subroutines, it has guidelines and pointers of when you should break things into functions. If you have some algorithm where those rules don't apply, that may be a good reason for having a long function.

Answer 3

Functions can get longer over time, especially if they are modified by many sets of developers.

Case in point: I recently (~1yr or 2 ago) refactored some legacy image processing code from 2001 or so that contained a few several-thousand-line-functions. Not a few several-thousand-line-files - a few several-thousand-line-functions.

Over the years so much functionality was added to them without really putting in the effort to refactor them properly.

Answer 4

Lots of values in a switch statement?

Answer 5

The very long functions I come across are not written in C, so you'll have to decide whether this applies to your research or not. What I have in mind are some PowerBuilder functions that are several hundred of lines long, being so for the following reasons:

• They've been written over 10 years ago, by people who at that time did not have coding standards in mind.
• The development environment makes it a bit harder to create functions. Hardly a good excuse, but it's one of those little things that sometimes discourages you from working properly, and I guess someone just got lazy.
• The functions have evolved over time, adding both code and complexity.
• The functions contain huge loops, each iteration possibly handling different kind of data in a different way. Using tens(!) of local variables, some member variables and some globals, they have become extremely complex.
• Being that old and ugly, no one dares refactoring them into smaller parts. Having so many special cases handled in them, breaking them apart is asking for trouble.

This is yet another place where obvious bad programming practices meet reality. While any first year CS student could say those beasts are bad, no one would spend any money on making them look prettier (given that at least for now, they still deliver).

Answer 6

Anything generated from other sources, i.e. a finite state machine from a parser generator or similar. If it's not intended for human consumption, aesthetic or maintainability concerns are irrelevant.