I know Bill isn't a fan of global variables but I posted a tribute at QBF

[Pete]

https://www.tapatalk.com/groups/qbasic/viewtopic.php?f=648955&t=39420

For those who are not registered there, please fell free to use this thread to discuss any preferences you have about global variables vs local variables and passing variables to subs.

Pete

[luke]

QB forces/encourages you to use global variables because it lacks good alternatives for structuring data; there are limits on what you can do with arrays and UDT's not found in other languages (you also are pretty strictly limited in what functions can return but that's more an annoyance than a real problem).

I dislike having more hidden state than absolutely necessary to keep track of, and I find it far easier to reason about code when it's clear what a function's value can depend on. There's also the endless battle to make sure the globals are initialised properly all the time (same goes for static variables, which are really the same thing with less visibility).

There's also the inherent issue of globals preventing routines from being called recursively or from two sites with different sets of state. I like to try and keep state contained in a UDT to pass around but often they're just not capable enough.

I can't say I have much of an issue with having to remember parameter orders or change signatures; it's somewhat unusual that I'd write a routine that takes more than 3 or 4 parameters. A better IDE with refactoring features (all the hip and modern IDE's let you say "change this function" and they fix every line that calls it too) would help as well.

[Pete]

One advantage QB45 had over QB64 was multi-modular programming. DIM SHARED would create global variables for a module, whereas COMMON SHARED was needed to share those variables across modules. This was especially helpful if you used like-named DIM SHARED global variables in other programs and wanted to put two or more of those programs together without changing all of the variable names. I know, sloppy engineering, but it got the job done. I'm pretty sure when God made the world, he programmed it this way in QB45, otherwise he'd still be at it. on the 8th trillion day, etc., and don't get me stated on Hell. You need FreeBASIC for that.

@ luke: Great in depth reply on the mechanics of variable use. Not having experienced other programming languages I can't say I fully understand it, but from the perspective of structure and working in programming groups it makes perfect since. I can also see the value in that IDE function, in fact I'm fairly certain I made something like that to change variable names and calls to subs and functions for program modifications before I discovered multi-modular programming in QB. That, and my own REMLINE routine.

Pete

[_vince]

One advantage QB45 had over QB64 was multi-modular programming. DIM SHARED would create global variables for a module, whereas COMMON SHARED was needed to share those variables across modules. This was especially helpful if you used like-named DIM SHARED global variables in other programs and wanted to put two or more of those programs together without changing all of the variable names. I know, sloppy engineering, but it got the job done. I'm pretty sure when God made the world, he programmed it this way in QB45, otherwise he'd still be at it. on the 8th trillion day, etc., and don't get me stated on Hell. You need FreeBASIC for that.

This is one of the major blind spots of QB64, I think, the lack of easy multi-modular programming. This would allow much larger and more complicated projects to be developed with much faster compilation. The only way to achieve this in QB64 so far is DECLARE LIBRARY.

The modern way to do multi modular programming is distinct from the old QB45 and DOS way.  You'd want to break your large program into SUBs and FUNCTIONs to be compiled as separate object files to be linked together.  One convention to share global variables is to put that code in a convenient header file to be included with $include "module3.bi".  Since there is usually more than enough memory to hold the program execution code, only data is dynamically allocated. In the case of dynamically linked libraries, ie DLLs, the program execution code can also be loaded and unloaded.

[SMcNeill]

If  Galleon ever gives us a backup of the .net forums, Michael had several examples of using QB64 to compile, create, and use DLL files instead of EXEs.  You needed to DECLARE LIBRARY the SUB/FUNCTION to use them, but it was a viable substitute method for modular programming. 

I may have to play around some and see if I can duplicate his process if the .net forums never become available again.  ;D