|
Well, I "disclaimerd" anything more than one statement! <g> Frankly, the one-statement subroutines I've seen will always only be one statement. Of the hundred or so subroutines I've seen in my career that only do a SETON LR, I've never seen them changed to do more than that. Why presuppose that the possibility exists someday that there will be more to a "function" than the one or two statements that the "function" needs now? If it does happen, that would be the time to separate the function into its own subroutine / subproc. Really, we could take this to the extreme and say that every line of code is a potential function in and of itself that could grow. So why not avoid the inevitable and give every line of code its own subroutine / subproc? - Dan --- rob@dekko.com wrote: > The problem is that the subprocedure/subroutine often grows. And, since > you started it right in the first place, it grows right. > > For example, I was once questioned on this list why I would do > C/Exec SQL > C... > C/End-Exec > /free > // one line of code > /end-free > C/Exec SQL > C... > C/End-Exec > > But once I explained that how do you make a decision that the line has now > exceeded a predetermined minimum number of lines needed to justify > converting to free form? Especially when people are loath to change code > that is working. But if you start out right... > > Rob Berendt __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.