When you can say a method has too many lines of code?

Kevin McFarlane

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

Marc Clifton

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

Thyme In The Country

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

Kevin McFarlane

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

WillemM

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?

Zac Howland

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

WillemM

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?

Lost User

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

JWood

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

FlorianS

The author was talking about the method itself not about the test case. Regards, Florian Szoke

FlorianS

The author is talking about the method itself not about the test case. Regards, Florian Szoke

Colin Angus Mackay

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

Lost User

Boredom. :)

Kicking squealing Gucci little piggy

S76

A method is supposed to do ONLY ONE THING. If it does more than that ... it ain't right. # of lines don't matter.

Kevin McFarlane

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

Zac Howland

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

El Corazon

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)