11-12-2022, 04:52 AM
For solo programming, I say do whatever works best. For team projects, I would use SUBS and FUNCTIONS. Why? Productivity. Individuals are almost always more productive doing things in the coding style they like. Teams, on the other hand, benefit from consistency and management by bringing different SUBS and FUNCTIONS together to work correctly with the MAIN. Usually team members are assigned a task, which is relegated to a particular SUB or FUNCTION. All the team developers have to do is make their variables, required by the main and other SUBS and FUNCTIONS, documented so they can be passed by either reference or value. For passing variables, I'd say the best approach is to use TYPE variables as much as possible. (Note arrays cannot be passed as TYPE variables.) Anyway, TYPE variables allow for several variables of a TYPE to be passed by TYPE, instead of each variable needing to be added to the list of parameters. Another way is to just make all variables COMMON SHARED or SHARED. The drawback is naming in that you must make sure you don't use a SHARED variable name you do not intend to be passed to another SUB or FUNCTION. Again, using TYPE variables help here, as well.
AS for GOSUB and GOTO, two different animals, really. GOTO is almost like a patch keyword. Forgot something in an almost completed program? Patch it with GOTO and a label instead of redoing the code. To use GOTO as a coding practice makes debugging code very difficult. Hence the nickname, spaghetti code. In a few instance though, GOTO is the most optimized way of achieving the proper flow. We have a keyword, _CONTINUE, which allows users to skip stuff in a loop, which would be like coding the label, "SkipHere:" above the LOOP statement then putting a GOTO SkipHere, where needed, in the loop. GOSUB, on the other hand, is like having the power of a SUB without having to pass variables. It always returns to the point it was called, so it is easy to debug, especially if you don't get into nesting. (Nesting is putting more GOSUB statements in a GOSUB statement. Anyway, nesting aside, GOSUB is a code saver when you need to call the same procedure more than one time. GOSUB can also help you visualize your program flow better, because instead of wading through many non-descriptive lines, you go from one well named procedure like GOSUB accounting: GOSUB display: GOSUB UserInput.
Pete
AS for GOSUB and GOTO, two different animals, really. GOTO is almost like a patch keyword. Forgot something in an almost completed program? Patch it with GOTO and a label instead of redoing the code. To use GOTO as a coding practice makes debugging code very difficult. Hence the nickname, spaghetti code. In a few instance though, GOTO is the most optimized way of achieving the proper flow. We have a keyword, _CONTINUE, which allows users to skip stuff in a loop, which would be like coding the label, "SkipHere:" above the LOOP statement then putting a GOTO SkipHere, where needed, in the loop. GOSUB, on the other hand, is like having the power of a SUB without having to pass variables. It always returns to the point it was called, so it is easy to debug, especially if you don't get into nesting. (Nesting is putting more GOSUB statements in a GOSUB statement. Anyway, nesting aside, GOSUB is a code saver when you need to call the same procedure more than one time. GOSUB can also help you visualize your program flow better, because instead of wading through many non-descriptive lines, you go from one well named procedure like GOSUB accounting: GOSUB display: GOSUB UserInput.
Pete
If eggs are brain food, Biden takes his scrambled.