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?
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.
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.
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.
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
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.
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.
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.
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.
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
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 =]
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
