When should I break a function?

Question

Its prudent to break a long function into a chief function and helper functions.

I know that the outside the module only chief function will be called, but its long length may prove to be intimidating.

Textbooks put a limit on the number of lines, but I feel that this is too rigid.

P.S. I am programming in Python and need to process incoming, messages. The function returns a tuple containing the message but in Python's internal data types. So you can see somewhat independent code for each message type.

Duplicate Question

When is a function too long?

Answer 1

I'm not a big fan of breaking a function into multiple functions unnecessarily. It's not a hard and fast thing - if there are things that seem like distinct logical units, then by all means, break those out and think about them separately. But don't just break things out for the sake of some guideline like "one page per function" or "N lines per function".

Answer 2

I think you need to go about this from the other end of the problem. Think bottom-up. Identify small units of work, as small as possible, and start composing your code that way. You will only run into spaghetti-code issues when you code top-down and don't keep a structured approach.

If you already have spaghetti code and need to refactor, you pretty much have to start over. It is probably more work to break up existing spaghetti code than to rewrite it, and the result may not be as good.

I don't think there should be a hard number for the lines of code in a method either, but well written code does not have methods with more than 5 to 10 lines in the lower layers, and 20 to 30 lines in the business logic. To give you some kind of metric.

Answer 3

Never write a function that, when printed on fanfold paper, is taller than you are.

Answer 4

One good rule of thumb is that if it doesn't fit on a single screen it is worth thinking about splitting it up. But only if it makes sense to split it up, some long functions are perfectly readable and it doesn't make any sense to slavishly split them into multiple functions just for the sake of it.

Answer 5

I like the rule of thumb that you should break out the subfunction if you can think of a good domain-relevant name for it.

When someone can understand the top-level function without necessarily having to look up the definition of the sub-function, you've likely made a net gain. (But when you break it down too far, your names start referring to your implementation artifacts rather than the domain)

Answer 6

I was recently discussing this with a friend. He suggested refactoring to separate concerns and I must say I have to agree. That is, one function should do one thing, if it does more than one thing, split it up. If not, let it be together, it makes no sense to split up a function, only to have it obfuscate the meaning. After all, a function is a block of code that does one thing!

Answer 7

The limit in term of number of lines is often impractical becuase it doesn't account for readability well. It's better to try to seperate groups of lines of code that have just a few inputs and just a few outputs and make this a separate functon. It's not always possible - then it's often wise to just leave the code as it is and not to refactor for the sake of refactoring.

Answer 8

Well since I am coding in Python so I have the liberty to write functions inside functions, unlike C, C++ or Java. This i feel is a better choice.

Answer 9

It's not specified. But line should be as low as possible. But you may follow the Role of 30. I follow this in my PHP scripts when needed.

Rule of 30:

“Rule of 30” in Refactoring in Large Software Projects by Martin Lippert and Stephen Roock:

• Methods should not have more than an average of 30 code lines.

• A class should contain an average of less than 30 methods.

• A package/library shouldn’t contain more than 30 classes.

• Subsystems should avoid more than 30 packages.

• A system more than 30 subsystems may create problem.

If an element consists of more than 30 subelements, it is highly probable that there is a serious problem.

Answer 10

personally I break a function if it either saves total lines or total processing time.

if I only run the helper once per chief function I don't bother

Answer 11

The point is that in principal it's better to have specialiced functions. But where one sets the limit depends very much on 1) the "usual" programming style in certain languages. (one can observe that, object-oriented langauges tend to shorter procedureds than let's say C or the like 2) it depends on your way of programming. Every hard limit must be questioned. IMHO. Overall there will probably some "natural" distribution of programs 3) I think what one should keep on one's mind is that a function should do a certain task take for example some function for parsing it is usually much longer than a function just settin some field in a structure. Or getting back just consider how a event loop in the Windows API may look. So that all suggests that there may be good reasons for long methods...

Answer 12

If there is independent code (in your case specifics for each message type) those areas should be broken out.

Answer 13

Size matters not. Judge me by my size do you? - Yoda

Your main concerns are readability, simplicity and maintainability. A good indicator is if you need to write comments to explain a section of a function then that section is a good candidate for a separate function.

Answer 14

There are many reasons to break a long function into its constituent pieces. Most important is:

• readability
• maintainability
• code clarity/intent

Some functions simple cannot be broken into smaller pieces without negatively impacting the listed goals, so there is no hard-and-fast rule.

Answer 15

If you didn't write it and it's already in production: NEVER!!! If you break it up, you're likely to break it, it's that simple.

If you are writing it and you're not sure, the on screen rule apples as others have said.