how big should function length be (lines of code in a function)? [duplicate]

Question

Possible Duplicate:
How many lines of code should a function/procedure/method have?

I would like to know how many lines of code should be function have? How many lines is too much.

I read this a while back, it around 10 or 20 lines but it was because the screen would only accommodate so many lines. Now as the screen size become larger, that would not hold true.

Let's assume that the no part of the function is used anywhere else i.e. disregard DRY principle.

I'd like to hear what others have to say about this.

thanks.

Note: Duplicate of When is a function too long?, could not find it when I posted.

Onestep

Before we can answer this, we need to define "line of code". – Nickola

Twenty seven and a half. – Untouchable

will, thanks for the pointless comment. hope you're feeling better. – Onestep

Answer 1

This kind of question is well answered in Code Complete. Steve McConnel wrote an entire page to answer this question. His conclusion:

Decades of evidence say that routines of such length (>100 lines) are no more error prone than shorter routines. Let issues such as the routine's cohesion, number of decision points, number of comments needed to explain the routine, and other complexity-related considerations dictate the length of the routine rather than imposing a length restriction per se. That said, if you want to write routines longer than about 200 lines, be careful.

Impasse

Answer 2

Lines are irrelevant, but complexity is.

A function should do one task, and it should be readily apparent. It shouldn't take you more than a few moments to understand exactly how and what the function does.

Deryl

What about a "controller" or "main loop" in my experience those tend to be a bit more complex than a single purpose function - maybe I'm doing it wrong of course... I agree with your comment in general, but think that there are always exceptions – Nudism

@blissapp: well, there are always obvious exceptions ;) – Competition

Answer 3

It should have as many as it needs.

I don't see any point in restricting a function line-count to screen size (ok to be fair, I didn't start programming until after screens could accomadate more than 10-20 lines - maybe this did make sense in some environments). Just write the function as it makes sense to. When it gets so large that pieces of code start repeating, refactor those pieces to other functions/classes/components.

Competition

Answer 4

It's a pretty arbitrary rule of thumb. Some like 20 lines, others like the no-scroll rule. In the end, just make sure it's readable and easily understood at a glance. Read over your SOLID principles and make sure the method has only 1 responsibility, etc.

Downrange

Answer 5

As long as necessary, as short as possible.

I take 5-10 Lines as a rule of thumb but if there is some logic that can't be (re)factored easily into multiple functions i write longer where necessary. On the other hand i often have functions that are just a line or two long.

If you do not immedatly understand what a part of code does, write a new function for it.

Kinesics

Answer 6

I've heard the screen size metric before too but obviously not intended to be a hard limit or to scale with monitor size. It's just intended to convey the principle of DRY and that keeping functions as small as possible is one of the best ways to write code that can scale (in project size).

Pyatt

Let's assume that the no part of the function is used anywhere else i.e. disregard DRY principle. Changed the question regarding DRY principle. – Onestep

Part of the function may not be used anywhere else today, but what about tomorrow or next year? When you come back to the code and need to use that piece of functionality, is it readily available in its own function or will you have to pry it out of an existing function? When you get to that point, it might be too much work or too destabilizing to re-factor the old function, so you just copy the piece you want. This is a major way in which DRY gets violated. You'll very rarely regret making an extra function or class but you'll often regret NOT doing it. – Pyatt

Answer 7

The Linux Kernel Coding Style document says:

Functions should be short and sweet, and do just one thing. They should fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, as we all know), and do one thing and do that well.

Now, I realize this is in the context of kernel code, but I think some of the points it makes re: function length are generally valid. Find a copy here. The section on functions is Chapter 4.

All in all, function length shouldn't be constrained by some artificial rule; factor stuff out if it makes sense, and because it makes stuff easier to read, but the rule about 1-2 screens is not written in stone.

Yenyenisei

Answer 8

this is just an opinion from an oo-perspective:

i prefer to keep my methods in logical units of work and dont really care about metrics like LoC. this makes it also quite easy to properly name your methods, and keeps them from getting bloated.

a very trivial functional example would be instead of having a function that calculates the fibonacci sequence inline in a loop i would add a successor(int a,int b) function, that gets called by the fibonacci() function.

a more complex example in oo fashion would be a http client that performs a GET request. i'd break that up into something like this:

Connection getConnection(String host, int port)
Request createRequest(String[] params)
void sendRequest(Request r)
String getResponse(Connection c,Request r)

Trilateral

Answer 9

Functions should be exactly small enough to do their job, but no smaller.

Nudism

Answer 10

I don't think it matters how many lines it has...as long as it's efficient.

Any code that can be reused anywhere in your codebase should be moved to another function/method in the same class or a shared class and called.

Lid

Size does matter - readability is very important, and when confronted with a wall of text, we programmers (being all efficient) glaze over the function. I know, we all like to pretend we don't, but we do. – Nickola

You can make code readable without creating more functions. – Lid