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 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:
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?
If the 6 lines of code did something trivial that should have been accomplished in 2 lines, then yes, he would be right. Without more information, and without seeing the 6 lines of code, it's hard to form a solid opinion on this though.
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox 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?
I once refactored a bit of code that someone had written that had 1500 lines of code in one method. I'd say that was too much.
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
-
Florian Szoke wrote:
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?
If the 6 lines of code did something trivial that should have been accomplished in 2 lines, then yes, he would be right. Without more information, and without seeing the 6 lines of code, it's hard to form a solid opinion on this though.
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blogThe point is not about the efficiency is the code, but when you will start to break a method in smaller methods. Of course if some part of the code can be used in more places you will do it, but if the code it is not shared . The idea is to make smaller method to be easier to be tested using unit testing Regards Florian
-
Florian Szoke wrote:
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?
If the 6 lines of code did something trivial that should have been accomplished in 2 lines, then yes, he would be right. Without more information, and without seeing the 6 lines of code, it's hard to form a solid opinion on this though.
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blogNishant Sivakumar wrote:
If the 6 lines of code did something trivial that should have been accomplished in 2 lines, then yes, he would be right.
See, I'd go the other way around. I used to do lots of stuff like this:
return SomeObject.Blah().DoDaa(OtherObject.Thingumgy.Bob);
And now I'd write it as:
Thing theThing = OtherObject.Thingumy;
Bob theBob = theThing.Bob;
Blah theBlah = SomeObject.Blah();
int result = theBlah.DoDaa(theBob);
return result;The latter is much easier to debug and step through. I now cringe when I see code like the former example above.
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 once refactored a bit of code that someone had written that had 1500 lines of code in one method. I'd say that was too much.
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'm currently refactoring VB.NET code that has a single function in each module, ranging from 600-1300 lines each. Each function performs a similar operation on a different set of source data. Just by using a few classes and some basic inheritance, I've cut it to less than half of its original size. So, yes. I'd agree with you that 1500 is too much. And So is 600. X|
The StartPage Randomizer | The Timelapse Project | A Random Web Page
-
Nishant Sivakumar wrote:
If the 6 lines of code did something trivial that should have been accomplished in 2 lines, then yes, he would be right.
See, I'd go the other way around. I used to do lots of stuff like this:
return SomeObject.Blah().DoDaa(OtherObject.Thingumgy.Bob);
And now I'd write it as:
Thing theThing = OtherObject.Thingumy;
Bob theBob = theThing.Bob;
Blah theBlah = SomeObject.Blah();
int result = theBlah.DoDaa(theBob);
return result;The latter is much easier to debug and step through. I now cringe when I see code like the former example above.
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
Hey, Colin. I feel your pain! :) I'm in exactly the scenario you describe, having to maintain code like the former. And then when you get null reference exceptions... Apart from the debugging aspect it's easier to read and understand when it's broken down. P.S. I've also now started using "result" as the return value instead of "ret" and "retval"... :) I adopted that from the Eiffel guys.
Kevin
-
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