Forum: Ruby Method Size - Best Practices

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Pistos C. (Guest)
on 2006-05-09 18:04
Eric H. wrote:
> My unit tests typically tell me which line my errors are on.  You
> probably haven't written enough tests for your code or aren't writing
> small enough chunks of code.
>
> The biggest change writing tests has done for my coding is to give me
> smaller more descriptive methods rather than large methods that do
> too much.  A method that is more than 10 lines long is probably
> wrong.  A method that is more than 25 is most definitely wrong.

Poll (for everyone, not just Eric): What is good or acceptable method
size in your opinion?  On what factors does your range depend?

Pistos
Lou S. (Guest)
on 2006-05-09 18:29
(Received via mailing list)
On 5/9/06, Pistos C. <removed_email_address@domain.invalid> wrote:
> Poll (for everyone, not just Eric): What is good or acceptable method
> size in your opinion?  On what factors does your range depend?

Well, I won't chime in on the _recomended_ line count for a method,
but I think the _maximum_ should always allow the entire method to be
viewed at once.  Practially, that means it needs to be less than the
default number of lines on a terminal screen: so I'd say 24.
unknown (Guest)
on 2006-05-09 18:32
(Received via mailing list)
On Tue, 9 May 2006, Pistos C. wrote:

> Poll (for everyone, not just Eric): What is good or acceptable method
> size in your opinion?  On what factors does your range depend?
>
> Pistos

i think this is a bit silly really,  i have several image processing
programs
that are 5000 lines of code.  the longest method is around 100 lines and
alreadys calls 20 other methods.  breaking it down further would simply
obfusicate the code.  the size of methods it going to be related to the
complexity of the task at hand.  rather that thinking in arbitrarily
limited
terms like '10 lines' or '20' i think it's best to always strive to
write less
code and the make is clear first and fast second.  most of the time this
will
result in relatively short methods since nearly everyone ends up writing
ones
that are too long.  however it's not always the case and the key here is
'relatively' - breaking a 10,000 line libraray into 1000 methods just to
acheive some 10 line goal is just going to make your library impossible
to use
: at a certain point the pursuit of abstraction in code leads to
obfusication,
the artfulness is in finding that line in your application.

2 cts.

-a
unknown (Guest)
on 2006-05-09 19:06
(Received via mailing list)
Pistos:
> Poll (for everyone, not just Eric): What is good or acceptable method
> size in your opinion?  On what factors does your range depend?

A great method size is one line. Most of my methods come in at under
five lines. If I've got a method over that length, it's generally
because I'm expecting to throw it away shortly, or make it smaller at
some point.

Another good time to add a new method is when you need to add a comment
(within a method) to describe what a line does.

... I'd have to say that my sensitivities change though. But that's
where they are at the moment.

Cheers,
  Benjohn
unknown (Guest)
on 2006-05-09 19:13
(Received via mailing list)
Ara:
*snip*
> i think this is a bit silly really,  i have several image processing
> programs
> that are 5000 lines of code.
*snip*

Having written a lot of image processing and graphics code, I used to
also feel that way. I've generally found though, that it is possible to
break down these functions (once you find a reusable pattern in them),
and doing so does render them more understandable.

Sometimes they don't come out being as quick, and very ocasionally, a
nice way to write something can make it hard to optimise (often, I've
found that it makes it easier). In cases like this though, I start
wanting to describe my algorithm at a higher level, and have the actual
code be generated by some other mechanism.

Having said the above, I have had IP problems where I've not been able
to find a nice way to break them down, and have moved on as it's not
been that important, so I don't claim it is universally true :)
Robert K. (Guest)
on 2006-05-09 19:40
(Received via mailing list)
2006/5/9, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid>:
> >> wrong.  A method that is more than 25 is most definitely wrong.
> complexity of the task at hand.  rather that thinking in arbitrarily limited
> terms like '10 lines' or '20' i think it's best to always strive to write less
> code and the make is clear first and fast second.  most of the time this will
> result in relatively short methods since nearly everyone ends up writing ones
> that are too long.  however it's not always the case and the key here is
> 'relatively' - breaking a 10,000 line libraray into 1000 methods just to
> acheive some 10 line goal is just going to make your library impossible to use
> : at a certain point the pursuit of abstraction in code leads to obfusication,
> the artfulness is in finding that line in your application.
>
> 2 cts.

4 cents now.

Kind regards

robert

PS: Luckily Ruby methods tend to be shorter anyway.
Christian N. (Guest)
on 2006-05-09 20:57
(Received via mailing list)
Pistos C. <removed_email_address@domain.invalid> writes:

> Poll (for everyone, not just Eric): What is good or acceptable method
> size in your opinion?  On what factors does your range depend?

  "I tend to break up a subprogram when there are too many local
  variables. Another clue is [too many] levels of indentation. I
  rarely look at length."
  --- Ken Thompson,
http://damienkatz.net/2006/05/signs_youre_a_c.html#comments

(via http://feeds.feedburner.com/projectionist?m=710)
Eric H. (Guest)
on 2006-05-09 22:40
(Received via mailing list)
On May 9, 2006, at 7:30 AM, removed_email_address@domain.invalid wrote:

>>> smaller more descriptive methods rather than large methods that do
> alreadys calls 20 other methods.  breaking it down further would
> writing ones
> that are too long.  however it's not always the case and the key
> here is
> 'relatively' - breaking a 10,000 line libraray into 1000 methods
> just to
> acheive some 10 line goal is just going to make your library
> impossible to use
> : at a certain point the pursuit of abstraction in code leads to
> obfusication,
> the artfulness is in finding that line in your application.

Exactly.

It is not my goal to write ten to twenty line methods, it falls out
from my use of TDD.  Large methods typically scare me.  Writing small
methods without tests would scare me just as much as writing large
methods with tests does.

I do have some very large methods and they do not scare me, they just
aren't logically divisible into smaller pieces.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Eric H. (Guest)
on 2006-05-09 22:50
(Received via mailing list)
On May 9, 2006, at 7:04 AM, Pistos C. wrote:

> Poll (for everyone, not just Eric): What is good or acceptable method
> size in your opinion?  On what factors does your range depend?

A good and acceptable method size should be almost entirely based on
comfort.  Trying to artificially constrain yourself is only going to
lead to bad code (and stress).

My coding style (with TDD) leads to 10 to 25 line methods because
those are most comfortable.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Simen (Guest)
on 2006-05-09 23:04
Eric H. wrote:
> On May 9, 2006, at 7:04 AM, Pistos C. wrote:
>
>> Poll (for everyone, not just Eric): What is good or acceptable method
>> size in your opinion?  On what factors does your range depend?
>
> A good and acceptable method size should be almost entirely based on
> comfort.  Trying to artificially constrain yourself is only going to
> lead to bad code (and stress).
>
> My coding style (with TDD) leads to 10 to 25 line methods because
> those are most comfortable.
Exactly. Break everything down into comfertable units, but not any
smaller. If a method does one thing and does it well, and there are no
patterns inside it that are common in your code, there is no use in
dividing it further into more methods.

That being said, if you have methods that are 50+ lines of code, those
should be the first to look for potential refactoring in.
James B. (Guest)
on 2006-05-09 23:11
(Received via mailing list)
Pistos C. wrote:

>
> Poll (for everyone, not just Eric): What is good or acceptable method
> size in your opinion?  On what factors does your range depend?

I aim for zero lines of code.  Fewer bugs.

But if I absolutely need code, then clarity and testing drive the method
length.




--
James B.

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.30secondrule.com   - Building Better Tools
Mike S. (Guest)
on 2006-05-09 23:17
(Received via mailing list)
On 9-May-06, at 3:04 PM, Simen wrote:

>>
>> My coding style (with TDD) leads to 10 to 25 line methods because
>> those are most comfortable.
> Exactly. Break everything down into comfertable units, but not any
> smaller. If a method does one thing and does it well, and there are no
> patterns inside it that are common in your code, there is no use in
> dividing it further into more methods.
>
> That being said, if you have methods that are 50+ lines of code, those
> should be the first to look for potential refactoring in.

Heh.  Recently a 4,500 line method caught my eye at work.  I ignored
the advice to wait until it was >5,000 lines before refactoring :-)

----------------------------
revision 36.3
date: 2006/04/14 21:57:08;  author: mstok;  state: Exp;  lines: +2119
-3887
first cut at refactoring xxxxxx
----------------------------

Mike

--

Mike S. <removed_email_address@domain.invalid>
http://www.stok.ca/~mike/

The "`Stok' disclaimers" apply.
James G. (Guest)
on 2006-05-09 23:43
(Received via mailing list)
On May 9, 2006, at 1:46 PM, Eric H. wrote:

> A good and acceptable method size should be almost entirely based
> on comfort.

This is a good point, I think.

I'm generally of the opinion the smaller the better.  The bigger
stuff makes me think too much.

However, there are other factors to consider.  For example, the
primary parser in FasterCSV is basically one method and it's longer
than I prefer to have them.  Unfortunately, method calls are pretty
expensive in Ruby and busting that tight loop into a bunch of small
pieces degrades performance a fair amount.  Since the primary reason
FasterCSV exists is to be quick, I leave it alone.  Now, I've
commented it as much as possible and tested it as thoroughly as I can
think to.  To use Eric's term, I am comfortable with the result.

James Edward G. II
Peter H. (Guest)
on 2006-05-11 03:45
Pistos C. wrote:

> Poll (for everyone, not just Eric): What is good or acceptable method
> size in your opinion?  On what factors does your range depend?

There is an excellent book named "Code Complete" by Steve McConnell that
does a really good job of answering this question and many, many others
about writing good software. I would recommend that you get it. It's
well worth the money =]

Cheers,
Tekhne
This topic is locked and can not be replied to.