Re: Mixing OO and DB

On Mar 8, 3:04 am, rp..._at_pcwin518.campus.tue.nl (rpost) wrote:
> Marshall wrote:
> >I'm going to argue that I have seen no evidence that writing
> >methods any smaller than 150 lines produces any measurable
> >benefits. I'm further going to argue that you haven't either.
>
> Neither have I, but there is an obvious argument: more modular
> code becomes easier to explain and easier to test. In my experience,
> 150 line method bodies can usually be chopped up into meaningful
> subroutines, i.e. with few dependencies. All kinds of subtle
> dependencies can hide in 150 lines that become explicit when you
> try to subdivide these lines.

Sure. I can't remember the last time I wrote a 150 line function. ...
For fun, I just looked at my most recent application. The longest method I could find was 33 lines, if you include the four blank lines and the five comment lines. And there were eight lines that contained only an open or close brace.

But that is my aesthetic preference. I don't know of any actual data that says there are advantages to keeping things short, below a threshold that was much higher that I had expected. (150-200 lines.) And I strongly reject any claims about "it's easier for me to read" or "I make fewer mistakes." I know enough about cognitive psychology to know that such subjective feelings are completely invalid. They might be wrong; they might be right, but the subjective feeling is useless as a predictor.

> Provided, of course, that you make
> these dependencies explicit as arguments; if they are going to be
> hidden away in global variables and the like, there's no benefit
> in subdividing the method bodies.

Agreed. Note that Mr. Martin actually advocates use of data members for this purpose. (Assuming I understand him correctly.)

Marshall Received on Sun Mar 09 2008 - 00:49:18 CET