Hi Steve,
I can see some scenarios were the use of public variables is applicable, IMHO, and I use them. Below are four examples where I find usefull to declare public variables:
1) Program starts, calls "HouseKeeping" routine (checks enviromnent, sets common stuff, see installation options etc). It (eventually) may detect that this is the first time this app is being run (installation process didn't finish yet). Sets the value of a global boolean flag to false (bInstalled=.f.). Proceeds with the installation process. Ask user for his/her install options etc. Creates environment stuff (generates .ini files, creates tables etc), declares some public variables to reflect what have been done and set their values (options, paths etc). These public variables are to be used only when program is finishing an install run. Return to main program. Main program detects it is in the middle of an install (bInstalled=.f.), sets some more variables. Calls startup routine.
2) Program starts, calls a "StartUp" routine (that reads .ini files, creates file paths etc). In there I use to declare many public variables and set their values, mostly those ones that'll receive values read from the ini file. It gets clear, and improves documentational aspects of the code being written, IMO.
3) At program initialization call a "SystemStuff" routine, that will declare many Public variables and Public Arrays, that will contain information to be used by all prgs of this app.
4) Inside a prg containing generic procedures that can be used by any app (SET PROCEDURE TO
), to declare and set variables/arrays to be used by calling programs (ex: main program calls proc A. Proc A declares Public variables. Main program uses Public variables declared by proc A). Some variables may never be used by the calling program, rather by some other procedure of that prg (ex: main program calls proc A, proc A calls proc B, proc B uses Public variables declared by proc A).
I understand that each programmer has his/her own way to structure a system and its programs. Think that sometimes to follow a strict rule (don't use public variables, one procedure must have just one return inside of it to exit...) you may create very confusing code (spaghetti logic?), being very hard to mantain it. Think good sense should prevail.
OTOH I see folks using OOP "ad nauseum", for everything they do, and you can even tell me that I could avoid declaring public variables, in the examples above, if I instantiated some classes (using parameters, properties, and calling their methods) to do what I'm doing with standard procedure calls :)
Regards,
Fernando
