When you can say a method has too many lines of code?
-
I am reading about Test Driven Development (TDD) and I found this quote: The author is talking about a method that has 6 lines of code. “This is an abnormally large amount of code to write in response to a test in TDD. Typically, steps are much smaller, although they can be this large if you are certain of the algorithm you need to use.” What is your opinion about this?
I think what he's trying to say is that, regardless of whether it's 6 lines or 6 inches, it depends more on the method than the size. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
I am reading about Test Driven Development (TDD) and I found this quote: The author is talking about a method that has 6 lines of code. “This is an abnormally large amount of code to write in response to a test in TDD. Typically, steps are much smaller, although they can be this large if you are certain of the algorithm you need to use.” What is your opinion about this?
I once read part of an OO book which said that methods should be no longer than 5 lines! But seriously I don't think you can quantify this except that you should generally strive for short methods. I think in the case of unit testing the methods should perhaps be shorter than the methods in the implementation code. I've just acquired a refactoring plug-in that also contains a simple metrics tool for cyclomatic and maintenance complexity, and I use these as guides. http://www.sharpsense.com/blog/CommentView,guid,9a07f446-a3e0-4a57-aa69-84ec3027df71.aspx[^] CC should be no greater than 10. MC should be no greater than 200 and ideally should be < 100.
Kevin
-
The writer is a moron.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
I agree, if you count a try.. catch block you will notice it has at least three lines if you type it like this:
try { } catch { }If you type it a little more readable with a method call inside it, you will need even more lines:try { doSomething(); } catch { logError(); }That's 8 lines and it is very testable if you ask me (Except for the exception handling, which sucks obviously ;P)WM.
Yaaarrrr What about weapons of mass-construction? -
I am reading about Test Driven Development (TDD) and I found this quote: The author is talking about a method that has 6 lines of code. “This is an abnormally large amount of code to write in response to a test in TDD. Typically, steps are much smaller, although they can be this large if you are certain of the algorithm you need to use.” What is your opinion about this?
Some of the responses to your question indicate to me that the posters are not familiar with Test Driven Development. What he is talking about is that 6 lines is abnormally large for a test case. Generally, the lines in a given test are 2-3 lines. That is, a method is created to call the proper method with either an expected success or failure. The result is compared to the expected result and the results are returned. Typically a given test will look like the following:
bool MyUnitTest::TestMethod1() { type expectedResult = whateverResultYouExpect; type actualResult = Method1(); return actualResult == expectedResult; }What some of the posters are referring to is functions in general. While it is hard to say sometimes, generally if your function is more than 25-35 lines long, it is probably doing too many jobs and should be split out into a couple functions. Sometimes, that isn't the case and it makes sense to have a function that is 50+ lines long (rarely). It is never acceptable to have a 1000+ line function (and yes, I've seen this in commercial code).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
I once read part of an OO book which said that methods should be no longer than 5 lines! But seriously I don't think you can quantify this except that you should generally strive for short methods. I think in the case of unit testing the methods should perhaps be shorter than the methods in the implementation code. I've just acquired a refactoring plug-in that also contains a simple metrics tool for cyclomatic and maintenance complexity, and I use these as guides. http://www.sharpsense.com/blog/CommentView,guid,9a07f446-a3e0-4a57-aa69-84ec3027df71.aspx[^] CC should be no greater than 10. MC should be no greater than 200 and ideally should be < 100.
Kevin
I think I have an idea about what was meant. I think he means that you don't need more than 6 lines in the testmethod. The method in the code that is tested may of course need more lines, depending on what you are trying to do. Its a good thing though to keep methods short, this helps you to understand the code better.
WM.
Yaaarrrr What about weapons of mass-construction? -
Some of the responses to your question indicate to me that the posters are not familiar with Test Driven Development. What he is talking about is that 6 lines is abnormally large for a test case. Generally, the lines in a given test are 2-3 lines. That is, a method is created to call the proper method with either an expected success or failure. The result is compared to the expected result and the results are returned. Typically a given test will look like the following:
bool MyUnitTest::TestMethod1() { type expectedResult = whateverResultYouExpect; type actualResult = Method1(); return actualResult == expectedResult; }What some of the posters are referring to is functions in general. While it is hard to say sometimes, generally if your function is more than 25-35 lines long, it is probably doing too many jobs and should be split out into a couple functions. Sometimes, that isn't the case and it makes sense to have a function that is 50+ lines long (rarely). It is never acceptable to have a 1000+ line function (and yes, I've seen this in commercial code).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
I am reading about Test Driven Development (TDD) and I found this quote: The author is talking about a method that has 6 lines of code. “This is an abnormally large amount of code to write in response to a test in TDD. Typically, steps are much smaller, although they can be this large if you are certain of the algorithm you need to use.” What is your opinion about this?
I don't know what TDD is but in my experience maybe the declaration - not the definition. I think this reliance on these policies that are supposed to be fool proof it fool hardy. No coding policy is fool proof.
A cynic is a man who, when he smells flowers, looks around for a coffin.
-H.L. Mencken -
Some of the responses to your question indicate to me that the posters are not familiar with Test Driven Development. What he is talking about is that 6 lines is abnormally large for a test case. Generally, the lines in a given test are 2-3 lines. That is, a method is created to call the proper method with either an expected success or failure. The result is compared to the expected result and the results are returned. Typically a given test will look like the following:
bool MyUnitTest::TestMethod1() { type expectedResult = whateverResultYouExpect; type actualResult = Method1(); return actualResult == expectedResult; }What some of the posters are referring to is functions in general. While it is hard to say sometimes, generally if your function is more than 25-35 lines long, it is probably doing too many jobs and should be split out into a couple functions. Sometimes, that isn't the case and it makes sense to have a function that is 50+ lines long (rarely). It is never acceptable to have a 1000+ line function (and yes, I've seen this in commercial code).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
Some of the responses to your question indicate to me that the posters are not familiar with Test Driven Development. What he is talking about is that 6 lines is abnormally large for a test case. Generally, the lines in a given test are 2-3 lines. That is, a method is created to call the proper method with either an expected success or failure. The result is compared to the expected result and the results are returned. Typically a given test will look like the following:
bool MyUnitTest::TestMethod1() { type expectedResult = whateverResultYouExpect; type actualResult = Method1(); return actualResult == expectedResult; }What some of the posters are referring to is functions in general. While it is hard to say sometimes, generally if your function is more than 25-35 lines long, it is probably doing too many jobs and should be split out into a couple functions. Sometimes, that isn't the case and it makes sense to have a function that is 50+ lines long (rarely). It is never acceptable to have a 1000+ line function (and yes, I've seen this in commercial code).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
Indeed. In fact, many of my tests are just one line:
void test_suite::test_some_method()
{
BOOST_CHECK_EQUAL(some_method(), expected_result);
}:) I am heavily into unit testing at the moment.
Kicking squealing Gucci little piggy
Out of curiousity: How come you changed your "screen name"?
Upcoming Scottish Developers events: * UK Security Evangelists On Tour (2nd November, Edinburgh) * Developer Day Scotland: are you interested in speaking or attending? My: Website | Blog
-
Out of curiousity: How come you changed your "screen name"?
Upcoming Scottish Developers events: * UK Security Evangelists On Tour (2nd November, Edinburgh) * Developer Day Scotland: are you interested in speaking or attending? My: Website | Blog
-
I am reading about Test Driven Development (TDD) and I found this quote: The author is talking about a method that has 6 lines of code. “This is an abnormally large amount of code to write in response to a test in TDD. Typically, steps are much smaller, although they can be this large if you are certain of the algorithm you need to use.” What is your opinion about this?
-
A method is supposed to do ONLY ONE THING. If it does more than that ... it ain't right. # of lines don't matter.
SmartCube wrote:
A method is supposed to do ONLY ONE THING.
...and the consequence of this is that methods will tend to be short.
Kevin
-
The author was talking about the method itself not about the test case. Regards, Florian Szoke
Florian Szoke wrote:
The author was talking about the method itself not about the test case.
This line: This is an abnormally large amount of code to write in response to a test in TDD. Indicates he is talking about the test and not the method itself.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac
-
I am reading about Test Driven Development (TDD) and I found this quote: The author is talking about a method that has 6 lines of code. “This is an abnormally large amount of code to write in response to a test in TDD. Typically, steps are much smaller, although they can be this large if you are certain of the algorithm you need to use.” What is your opinion about this?
Florian Szoke wrote:
When you can say a method has too many lines of code?
keep at 10% cpu overhead for organization and design. 90% should be function (internal operation), balance all your class methods plus or minus from that goal. At least that is what I came away with from all the performance classes at Game Developer's Conferences. If your calling overhead is 60%, you're loosing half your machine to your class calls. If you're at 5% calling overhead, you probably have huge unorganized functions that may not be a problem now, but they may be in the future. Zen it... find your balance.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)