|
> From: Scott Klement > > If the code gains no advantage from being a subroutine, I think a > subprocedure is a better solution. You seem to think the opposite. Why? > Why is a subroutine ever a better solution? That's the question. For me it's simple: extra lines of code. This is especially true in free form RPG where I have to add another free/end-free pair for every procedure. I also have to remember to go up to the top of the code and define the prototype. Here's a complete example: With Subroutines: d a s 1 d b s 1 /free exsr Sub1; exsr Sub2; *inlr = *on; begsr Sub1; a = b; endsr; begsr Sub2; b = a; endsr; /end-free 16 lines (3 blank). With procedures: d a s 1 d b s 1 d Proc1 pr d Proc2 pr /free Proc1(); Proc2(); *inlr = *on; /end-free pProc1 b d pi /free a = b; /end-free p e pProc2 b d pi /free b = a; /end-free p e 25 lines (4 blank). This is eight extra non-blank lines, not to mention the fact that all those procedure definition lines and free/end-free pairs tend to break up the flow of the code. If all I am doing is segmenting my code (as I often do in a state-driven architecture) then there is no reason to add the code. Especially since they're equally readable. I don't know about the performance; I haven't written a benchmark yet. Joe
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.