Global variable

[Han]

(06-26-2017 04:02 PM)DrD Wrote:  

(06-26-2017 03:09 PM)Han Wrote:  When several programs start using the same reserved variables, and those programs should happen to call each other, then you can easily imagine the mess that could result. But the other (bigger) reason for avoiding them is if a user makes frequent use of these variables for their own quick calculations, then your program could very well destroy their data. My personal philosophy is that all programs should never touch a user's data and leave every global variable, setting, flag, etc. as they were unless the program is designed to explicitly modify the user's data and/or system settings.

Programmer's willing to use global's must consider the consequences. What you see as a pathway to trouble, I see as potentially added value. Every program step must be considered, if there is a reasonable expectation for success. Global variables are no different, and is yet another tool that can offer efficiency. My personal philosophy is, I see greater value in the global features, and no more risky than a myriad of other existing commands or functions.

I agree with your personal philosophy, and see no contradiction between us, where you say, " ... unless the program is designed to explicitly modify the user's data and/or system settings." Globals imply that there is a design to explicitly modify them, (or not). The debug advantage, or post processing advantage, and no requirement to declare them 'efficiency', are all good reasons to justify globals. I have come up with many programs, some just created in passing, or for examples, and some more robust that are in my master program list, that use globals exclusively, or in a mix combination with locals. To date, I have not seen any ulterior consequences, perhaps other than my own development pains, but nothing in the final work, that use of globals made into a mess.

Global variables, from a design point of view, are there so that users do not have to declare them for every use. Imagine for a moment if global variables did not exist from a user standpoint (and without even brining in programs into the picture). Such a setup would be very tedious. I am sure that this is only one of the reasons for the existence of (system) global variables. That their availability it is also a convenience to the programmer does not mean that programmers should just haphazardly modify the contents of such global variables. If your programs are for your own personal use, then I see no problem. But if you were publishing your programs, then I think it is plainly a matter of courtesy in not tampering with the global variables -- or at least restoring their contents after completion.

Quote:Other than fear of ambiguous scenario's that "could happen," are there any tangible reasons not to use globals, that you can think of? Sure, you can create a program, and destroy the global data content it relies on, but such a program still works as you designed it. Thus its not a tangible reason to blame the use of global's for those consequences. The same can be said for any other aspects of a program structure. A program is only as good as its actual design, warts and all.

Just because a program runs without bugs does not mean it cannot have undesirable effects. As already stated, if your programs are for public consumption, and they modify the users' data already existing in (system) global variables, then I think that is bad practice (just my own personal opinion). Sure, they make debugging and programming easier, but you can access any program's variable from the command line -- even if not exported -- by simply fully qualifying them. And their contents persist even after the program ends. So there really is no reason to be using system variables once you are at the stage of publishing your program. Lastly, even if you do use the global variables, a quick search and replace (with locals) once your coding is complete would also ensure that user data will never get tampered by your programs. If that is too much trouble, even a wrapper program which stores the user's contents prior to running, and restoring them after completion, would be preferable in my opinion.

Code:


UserData:={};

mywrapper()
begin

// program modifies L1 and L2
UserData:={}; // force reset
UserData(0):=L1;
UserData(0):=L2;

myprogram();

// restore L1 and L2
L1:=UserData(1);
L2:=UserData(2);

end;

EDIT: I would even go as far as to suggest minimizing the use of EXPORT.