There is a place for this type of construct. In very large systems you'll sometimes find numerous places where 'the location' logic is performed (as an example). Then you have a user co-funded development to make a big change to the location logic. Now you have to *find* and change those 360+ programs. Been there, done that.
Had a little more imagination been used prior to creating those 360+ programs, the project could have been done by changing one common subroutine. In the same system, the billing is all done by the same common subroutine, and it does do a lot of different stuff depending on who's calling it. But when you change billing, it's all done in one program (well, actually a chain of programs, but each one does it's own piece and nothing is duplicated). Saving big big dev time. Sure it's harder to change and do it right. But you know it took me almost 6 months to find and change all the location programs, and then 6 months later I had to do it again for another co-funded project and discovered some that I missed the first time because the person had been unusually creative in using non-standard file and variable names. *(a big DOH moment for me)* So about a year of my life was spent on the most boring, tedious and unrewarding search, modify, test, and move to the next one mundane programming that I have ever done. Trust me, the changes I did to billing were wonderful and swift and sweet in comparison. More difficult in brain power yes, but they were some fairly big changes and only took a couple of weeks instead of 6 months. If I had changed all those programs to call a central subroutine the first time, it would have probably taken another month, but then the second time would have been a couple of weeks instead of another horribly painful 6 months. T'was like a bad dream that I couldn't wake up from !!!!!! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Kevin King Sent: Saturday, February 11, 2006 09:09 To: [email protected] Subject: RE: [U2] [UV] GOSUB variable-name? [EMAIL PROTECTED] asked: >Many called subroutines are "told" what to do by the caller. What's the problem with that? While I agree that passing a parameter into a subroutine to tell it what to do is a common practice, it has the side-effect of obfuscating the functionality of the subroutine. For best readability, a subroutine should perform one basic function that is obvious either from reading the code or the embedded comments. When a single subroutine performs several dozen different tasks based on an incoming parameter, that's all the more code to have to decipher when trying to figure out what that subroutine does six months after the fact. Now this is not to say that the technique doesn't have a time and place. I've used this technique to create a generalized tax calculation routine where the country code is a passed parameter, and then the subroutine has a big CASE statement to determine which tax routine is to be used for each country. This subroutine then calls other external subroutines for the calculations per country; embedding all that logic for all countries into one subroutine would have made for a readability disaster. I firmly believe that one of the most significant productivity drains on any software project occurs when someone takes on a piece of code they've never seen before (or can't remember) and the objective of that code is not obvious from the context, code, or commenting. When this occurs, there's a period of "what the [EMAIL PROTECTED] does this thing do", which is much easier to determine when the code is small and focused on one task vs. large and multi-purpose. While I know of no metrics to prove such a claim, I believe this issue is one of the leading causes of excessively long development times and incremental maintenance instability resulting in projects that are much more expensive, inflexible, and buggy than necessary. The old party line about keeping everything inside of one subroutine to avoid the overhead of calling other subroutines may have been applicable a decade ago, but with the speed of todays machines and the sophisticated caching in these environments such overhead is largely (though admittedly not completely) mitigated. So as long as we're dedicated to these decades-old methods, in the end we're doing little more than producing less results that are more difficult and more costly to maintain. My apologies if this comes across a little strong. I'm just very tired of seeing our jobs go overseas because corporate America thinks that domestic software development is so expensive and this day-to-day repeat of outmoded implementation tactics is doing nothing to prove them wrong. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
