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

This question already has answers here: Closed 12 years ago.

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.

---

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.

---

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.

---

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.

---

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.

---

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.

---

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.

---

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).

---

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.

---

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)

---

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