We all know (or should know) that it's a good idea to keep your methods short. I've seen it
recommended that they should be more than 7 ± 2 lines (
Update: Although I still have seen it recommended they should be that short, I didn't mean to imply that I haven't seen other recommendations. Steve McConnell's Code Complete 2 says 50, I think, as Peter Bell alluded to in the comments below). The goal, of course, is simply to manage complexity,
so as long as you've accomplished that, you're ok.
I've generally just created methods for three purposes that I can identify (in no particular order):
-
Follow the DRY Principle:
Refactor common code out into one method.
-
Create an interface for a class
-
Reduce complexity: Sometimes, I see some code that is hard to understand or is a long
related block (such as
setDefaultVariablesScope()), so I'll put it into
a method so I don't have to think about it while I'm working on something else.
But sometimes, I think I can go further. And sometimes I do, while others I don't. There is a
common thread between most of these times I feel I could go further: if I could name the block
of code. And the commonality between most of the times I don't extract that block into a method: the code is not especially complex,
and I am too lazy to do it "right now."
So, I wonder, would it be a fairly valid rule to say "if you can name a block of code, put it in a method"?
Of course, you can't simply say "if you
can't name it,
don't put it in a method," since
it might be hard to think of a good name (or, it may just be that the code is not cohesive). But I think the other way might go a long way to reducing complexity
and making the code more easily understood.
What do you think? Do you follow any guidelines that you've noticed (either intentionally or not)?
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
I've seen the 7+/-2 suggestion, but I've also seen that trashed by others. Partially it is a function of the expressiveness of the language you're using - I'm not sure if the BOILERPLATE in Java would fit into 7 +/- 2 lines.
Coldfusion is better - but not by much.
I think it is more like a Haiku - an encapsulation of a single coherent thought. In practice I find my methods (excluding CF boilerplate which sucks - but that's another thing) run anything from 5-50 or so lines. If I can't see the whole thought on one screen, I need to refactor.
Posted by
Peter Bell
on Jan 25, 2007 at 05:16 PM UTC - 5 hrs
The 7±2 probably comes from this being the average human memory capacity for lists - the average person can remember seven items, with 5..9 being the range that includes most people.
For menus, it's a great idea - if you go over seven items, strongly consider grouping things, so that the menus are more usable.
I don't see how it applies to lines of programming code though.
Code should be logical, readable and efficient - the number of lines itself is only a byproduct of these, not something that should be specifically controlled.
I partially agree with Peter Bell - keep a function as a single coherent thought.
I can't really agree with the single screen part though: with a 1024x768 screen, I've only got 300-500 pixels (~20-30 lines) of code on a screen (depending on Eclipse panels), and many SQL queries or function calls easily take up much more than that, and they often cannot be shortened/refactored without making things harder to read/understand.
Posted by
Peter Boughton
on Jan 26, 2007 at 03:36 AM UTC - 5 hrs
Both Peters-
"an encapsulation of a single coherent thought."
Absolutely it is. The goal is not to have short methods, rather it is to have easily understood methods. It just so happens, I think, that methods with fewer lines are easier to understand more quickly than those with longer lines. Cohesion is the operative word here - as long as your methods are cohesive, you're doing a good job. But, I think the line length is an indicator that you might need to break it up. You can't simply say "no method must be longer than 7 lines!"
Peter Bell- Probably most of the boilerplate code could be pulled into methods itself. Of course, each situation is different. Not that I don't have tons of methods that are long, but nowadays, if I find myself writing a 50-line method, I would certainly look for a way to break it up.
In fact, it was a Java guru who I first heard the 7-line thing from (if my memory serves me like a waiter who wants a good tip), so I would think it is possible in Java. In fact, in general my methods in Java are shorter than the ones I write in CF.
Peter Boughton-
I think you're right about the list thing. But, I think it applies to code, since a program is just a list of instructions. And of course, I agree with the idea that the number of lines itself is only a byproduct of the qualities you mentioned. The idea behind keeping it to 7 lines or so, I think comes out of not having too much to concentrate on at one time. If you could keep your methods that fine-grained, can you image how much easier it would be to work with them two or three years from when you wrote it?
On the other hand, I completely see your point about the SQL queries. But, I am never thrilled with having to maintain those types of queries, or change them when they need changing.
Posted by
Sam
on Jan 26, 2007 at 01:12 PM UTC - 5 hrs
I Would Like To No How To Learn a method To Kepp Track Of Planets
Posted by Emma
on Jan 26, 2008 at 04:03 AM UTC - 5 hrs
Can You Think Of One I Can Do For School Write Back Emma
Posted by Emma
on Jan 26, 2008 at 04:04 AM UTC - 5 hrs
Leave a comment
