12-19-2005, 05:35 AM
Using GOSUB-style subroutines has the following consequences:
1. Any and all variables used within the subroutine must be global. There is no way to pass variables to GOSUB-style subroutines, so the only option for referencing variables outside the subroutine is to pollute the global namespace. This one fact alone should be enough of a deterrant.
2. There's no guarantee (read: mandate) of a GOSUB-style subroutine ever returning. If you don't manually return from the subroutine, your call stack will never get unwound, which can be quite a pain when we get to #3.
3. From #2, the chance of fall-through increases. Since GOSUB-style subroutines lack a definitive structure, missing a return statement or two has disastrous results.
Note that using functions (or subs) eliminates all three of the above bug-inducing situations. It is generally preferred, then, not to use GOSUB-style subroutines at all. It is a deprecated programming construct. Using them will only make your programming life harder.
1. Any and all variables used within the subroutine must be global. There is no way to pass variables to GOSUB-style subroutines, so the only option for referencing variables outside the subroutine is to pollute the global namespace. This one fact alone should be enough of a deterrant.
2. There's no guarantee (read: mandate) of a GOSUB-style subroutine ever returning. If you don't manually return from the subroutine, your call stack will never get unwound, which can be quite a pain when we get to #3.
3. From #2, the chance of fall-through increases. Since GOSUB-style subroutines lack a definitive structure, missing a return statement or two has disastrous results.
Note that using functions (or subs) eliminates all three of the above bug-inducing situations. It is generally preferred, then, not to use GOSUB-style subroutines at all. It is a deprecated programming construct. Using them will only make your programming life harder.
stylin: