Rule: Max Number of Lines Per SP

A client believes that "a stored procedure should never have more than about
50 lines of code in it."
No rationalle behind that thought.
When pressed - she stated, "I heard that in a class once a long time ago."
I think this person is an idiot.
Is there or was there ever a time when a such a rule made sense for
technical reasons?
I'm just trying to see how such a belief might possibly make sense.
Thanks.= u r idiot
Message posted via http://www.webservertalk.com|||>> A client believes that "a stored procedure should never have more
than about 50 lines of code in it." No rationalle behind that thought.
<<
Actually, there is both a rationale and a history. Return with me now
to the 1970's when Software Engineering was being born. We would put
bugs into code and give them to people debug, and measure them.
Fifty lines is about one page of hardcopy print out. We found that
code modules that can be seen in toto are measurably easier to maintain
than those that were split across pages or screens. The longer the
module got, the harder the bugs were to find (I cannot remember the
formula, but it was greater than linear). University of Maryland and
SEI had some of the studies, as I recall.
This pattern held across languages, which meant COBOL, FORTRAN, Jovial
and Assembler in those days, then later Pascal and C.
Notice that I said "module", so subroutines, paragraphs or procedures
count as modules depending on your language.
In the case of SQL Server, this was the rule because T-SQL was never
meant to an application language. It is a very simple one-pass
compiler that was used to "fill in the holes" in the early product by
giving you triggers for DRI and other thigns we do declarative today.
.|||Joe,
<<Actually, there is both a rationale and a history>>
YOU have an interesting rationalle. So does everyone else who responded to
my OP, and I agree with all of them to date.
The idiot manager had no rationalle floating around inside her head beyond
"I heard it in a class once." We talked at length... she really had nothing
more than that.
I just wanted to see if I was missing something... apparently not.
Thanks Everyone!
"--CELKO--" <jcelko212@.earthlink.net> wrote in message
news:1114720755.550812.61610@.g14g2000cwa.googlegroups.com...
> than about 50 lines of code in it." No rationalle behind that thought.
> <<
> Actually, there is both a rationale and a history. Return with me now
> to the 1970's when Software Engineering was being born. We would put
> bugs into code and give them to people debug, and measure them.
> Fifty lines is about one page of hardcopy print out. We found that
> code modules that can be seen in toto are measurably easier to maintain
> than those that were split across pages or screens. The longer the
> module got, the harder the bugs were to find (I cannot remember the
> formula, but it was greater than linear). University of Maryland and
> SEI had some of the studies, as I recall.
> This pattern held across languages, which meant COBOL, FORTRAN, Jovial
> and Assembler in those days, then later Pascal and C.
> Notice that I said "module", so subroutines, paragraphs or procedures
> count as modules depending on your language.
> In the case of SQL Server, this was the rule because T-SQL was never
> meant to an application language. It is a very simple one-pass
> compiler that was used to "fill in the holes" in the early product by
> giving you triggers for DRI and other thigns we do declarative today.
> .
>|||Guadala Harry wrote:
<nothing of importance>
Your choice of words and tone are troublesome...
David G.|||On Thu, 28 Apr 2005 13:03:19 -0700, Guadala Harry wrote:

>A client believes that "a stored procedure should never have more than abou
t
>50 lines of code in it."
>No rationalle behind that thought.
>When pressed - she stated, "I heard that in a class once a long time ago."
>I think this person is an idiot.
>Is there or was there ever a time when a such a rule made sense for
>technical reasons?
>I'm just trying to see how such a belief might possibly make sense.
>Thanks.
>
Hi Guadala,
As Joe indicated, there is some rationale for this rule. But it should
be treated as a rule of thumb. The point is to reduce complexity.
Suppose you have a query like this:
SELECT a.Col1,
b.Col2,
..
e.ColN
FROM Table1 AS a
-- Some useful comments here
INNER JOIN Table2 AS b
ON b.Col8 = a.Col4
INNER JOIN Table3 AS c
ON ...
...
WHERE d.Col18 = 'Asdf'
AND e.Col4 < b.Col8
....
ORDER BY a.Col1,
b.Col2,
...
c.Col8
It's very readable, but probably more than 50 lines. But yoou coould
squeeze it in a lot less lines:
SELECT a.Col1, b.Col2, ..., e.ColN FROM Table1 AS a
INNER JOIN Table2 AS b ON b.Col8 = a.Col4 INNER JOIN Table3 AS c
ON ... WHERE d.Col18 = 'Asdf' AND e.Col4 < b.Col8 ....
ORDER BY a.Col1, b.Col2, ..., c.Col8
But would it be easier to read'
A reverse example: back in my mainframe / Cobol days, creating a report
(or an external interface) required you to move all fields in the
records from the read file to the corresponding field in the records to
be written. Code like this:
OUTREC.FIELD1 = INREC.FIELD1;
OUTREC.FIELD2 = INREC.FIELD2;
...
OUTREC.FIELD138 = INREC.FIELD138;
WRITE FILE (OUTFILE) FROM (OUTREC);
I had a colleague who took the 50-lines rule way too literally - he
would break this routine in three subroutines, and call them after each
other:
CALL FILL_OUTREC_PART1;
CALL FILL_OUTREC_PART2;
CALL FILL_OUTREC_PART3;
WRITE FILE (OUTFILE) FROM (OUTREC);
Senseless overhead, IMO.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||<<Your choice of words and tone are troublesome>>
And ?|||And there are some general rules of respect and courtesy that everyone
should follow when posting. I think everyone understands your frustration -
we've all been there in one form or another (and perhaps even been the
source of frustration at times), but this isn't the forum for venting your
anger especially with insults, deserved or not.
Mike
"Guadala Harry" <GMan@.NoSpam.net> wrote in message
news:O7$gY2ETFHA.2124@.TK2MSFTNGP14.phx.gbl...
> <<Your choice of words and tone are troublesome>>
> And ?
>