Eric Wise

Thanks for "throwing down the 'gauntlet'" on something I clearly labeled as "my pain point".

You missed my point completely by choosing to focus on one tiny thing you found to disagree with.  Congratulations.

I agree with you in a way, classic example is a the IntializeComponent() method. Many a time, you have to re-initialize controls on a form based on some kind of data/user input, the code for which might run into a 100 lines at times, and breaking such a function into smaller units would be an overkill. A function/method should be a logical unit, and while most logical units can be written within 10-20-30 lines, some might not. Having said that, there are no excuses to ignore basic function/method design guidelines and leave these over for refactoring later.

That's the funniest 'first post' comment, ever.  Congratulations.

Eric, please go check the cyclomatic complexity of the code you have written, if it's high as I suspect, shame on you. :-P

@Ridge: I just thought the same thing... how am I supposed to take somebody seriously who writes

> You missed my point completely by choosing to focus on one tiny thing
> you found to disagree with.  Congratulations.

Sheesh...

I think everybody has a good story about bad consultants.

You don't split methods up just for possible re-use, you do it to make the code easier to understand and test.  Your LoadUserById/PopulateUser() is a good example.  Splitting stuff like PopulateUser() into separate methods IS valuable because you can see the overall flow of the parent LoadUserById() method without getting bogged down by the details of which IDataReader column goes into what User setter.  

Look at the Compose Method refactoring from Joshua Keriesvky's book --> http://www.industriallogic.com/xp/refactoring/composeMethod.html.  That's what small methods, with good names, can give you.

Invest just a little bit of time in the code navigation shortcuts in VS/ReSharper and you can easily bounce around the code.

Just to be a smartass because I know you're skeptical of all things agile, if you were doing TDD with granular unit tests you probably wouldn't have to spend nearly as much time in the debugger.

I think you codebetterans need to get a little more sleep and stop snapping at each other :)

Eric - you really are missing the point. You missed it the first time with the post, and then after Jeffrey calls out the flaw in your argument, you go and reiterate how you missed it.
"I would advocate that putting some magic line number constraint is a "pain point""
Nobody advocated a magic number constraint. Jeffrey never said "*YOU* should not create a method over 10 lines." Jeffrey never said "*I* never create a method over 10 lines." If he had made either of those statements, your disagreement would be understandable.

He basically said "I don't LIKE it when MY methods go over 10 lines".

How can you argue with that?

It's funny, because it certainly read to me like he was saying that no method should be more than 10 lines.

I guess if you go looking for an argument, you'll find one.

What line made you think "no method should be more than 10 lines"?
These are the lines I read (*starred* emphasis mine) and understood as a personal guideline - not a hard and fast law that everyone must live by.


"Here are *general rules* I try to live by"

"The method *should* be viewable without scrolling.  Fewer than 10 lines of code is *desirable* (*my* pain point)."

And i certainly guess I found one - thanks for stepping up josh. You are definately looking too, this I can tell.

So you want to analyse the nuances of language do you? For starters, you can stop quoting specific phrases and shouting out that there's nothing misleading. you take a specific phrase out of context, and of course you can find the meaning you're looking for.

But let's take your quotes.

>"Here are *general rules* I try to live by"

You're right. They're general rules, and they're his. And?
Well for starters, he's still called them rules. He didn't call them 'my general rules', he just called them general rules. The inference of this is that these are rules that should apply to everyone.

He's said he tries to follow them. The impression given is that he tries to follow them, and that I should too. That's the first impression I get. What other impression should I take? Well, he can only have listed these rules for one of two reasons. 1) because he thinks that everyone should follow them, or 2) because he's open to discussion on them, perhaps willing to change or remove some.

So which option is it? I stick with (1), because it's clear it's not (2). If it was two, he wouldn't have made a fool of himself in the first comment left on this post. If it was (2), he would have opened a discussion instead of acting all hurt and offended.

Next quote.

>"The method *should* be viewable without scrolling.  Fewer than
>10 lines of code is *desirable* (*my* pain point)."

Should. Why are you highlighting that? You want to get picky about specific word choices? OK then, let's see what 'should' means.

Should: Used to express obligation or duty.

Yes, it's not as strong as 'must' or 'will'. But it certainly leads me to the idea that he's saying it's a rule that had better be followed if at all possible. But the sentence it was used in was to do with 'viewable without scrolling'. Eric never said that was an issue, i've not commented on whether i agree with it or not, so i'll leave it alone.

Desirable. No idea why you're highlighting that word. Yes, it implies that the rule can be broken, but there's no mention of what circumstances cause an allowable exception.

My pain point. Yes, it's *his*. However, like I said above, if it's not open for discussion, then he's laying down the law. Which is it? If it's open for discussion, then hey, aren't some people trying to discuss it? If it's open for discussion, then shut the fuck up josh, and let us discuss it - stop trying to get your childish banter taking over the thread. If it's laying down the law, then shut the fuck up josh, you're obviously wrong by saying that he's not.

Yes, it's Jeffrey's pain point. That's fine. So he's allowed state his pain piont is a certain number, but Eric can't state that his pain point is the existance of any number? So now one person can talk about their own stuff (and if it's not laying down the law, it must be open for discussion right? If it's not, then it shouldn't have been published) but when someone els talks about _their_ own stuff, you have a problem with that because you think they're laying down the law?

Fuck dude.

Me, I'd like to think that all things are open for discussion. And if so, why the hell can't we discuss them? Why do you have to get all high and muighty and defensive? Why does jeffrey have to act like a tool with his comment above?

If your methods are only 10 lines or less, the methods probably are not doing anything really interesting.

For example, if you try to do this: http://en.wikipedia.org/wiki/Dykstra's_algorithm
and break it up into less than 10 line parts, I am not sure you have made the code any *more* readable, and in fact, have probably done the opposite.

Nobody would advocate for 200 line methods that scan 3 printed pages.  But 10 is clearly too few, and frankly, would contribute to additional code complexity by adding more methods that needed.

That said, if the highlight of your day is taking internal variables, constructing objects from them, and sending them to a database, then perhaps 10 lines gives you enough expressiveness to get the job done in most instances.  Most things that actually add value to a business, however, go a great deal more than that!

Interesting take Aaron. Jeffrey (if youre still listening), can you run some sort of static analysis on one of your real world apps and report how many methods exceed the 10 line threshold? Then report back on whether the application adds value to a business.
If the number of longer methods is more than 10%, then we can assume Aaron is right. If its less than 10% (and assuming your app actually adds value), Aaron is probably wrong. Or we argue about what the acceptable level of rule-breaker methods is - maybe 10% is too many?

Yes, I'm still watching this thread.  If I could take back my first comment, I would.  I was a bit short.

I've posted about some code analysis I did here:
http://codebetter.com/blogs/jeffrey.palermo/archive/2006/04/13/142797.aspx

I don't think about the number of lines when I'm coding a method.  I code to satisfy the test that I've already made.  The test is testing one thing, so my method just does one thing.  I have run into situations where I need to perform instructions in a loop.  I end up refactoring the body of the loop into another method for readability.  The size of a good method isn't a rule I made up, but it's an observation.  The end result (small methods) is very favorable.

The methods that _are_ 20 lines of code have good reasons for being so, but they seem to be the exception rather than the trend.