Some of you are taking this way too seriously. If I didn't know better, I'd think you were arguing about surrogate vs natural keys
You probably don't need another opinion but I thought I should share my original problem with globals which actually was fixed by A2007 or possibly A2010 and that problem was that Global variables used to loose their value if the app encountered an unhandled error.
That problem has not been fixed, Pat (as of A2013 that I am using). But as I pointed out earlier, it only exists if the app is not compiled into .accde.
I don't know about you, but I don't bother to put 10 lines of error trapping code into procedures that have only a few lines of code UNLESS, I know the procedure has the potential to raise an error. Of course I use extensive error trapping when I know errors will be raised but how likely are you to get an error when you have 10 lines of code that are clearing search boxes? So, since this was prior to TempVars, my solution was to create a hidden form where all "global" variables were defined as controls. The upside of this turned out to be that making the form visible during testing enabled me to monitor the variables as they changed and to actually step in and change values to alter logic paths when necessary. That in particular made it much easier to test the application security since I didn't have to keep loging out and logging back in as a different user.
I am not clear about the "upside". Are you saying that this could not be done with global variables without the form ? Eg. via the watch window ? I am not really clear about the benefit of spawning a form just to house a bunch of variables. Why not to put them in a parameter table?
So, even today, in the era of TempVars I still primarially use the form method. If I do use TempVars or Globals, I ALWAYS define them in a single standard module to make it easy for me to find them. My use of "globals" (any of the three methods) is very limited and as someone else already mentioned usually limited to things relating to the logged in user and security.
I personally see nothing wrong in using them also to pass parametric data between modules, in defining application settings, and in managing a session. Also, I am not sure why you would use globals in a standard module when you went into the trouble of creating a hidden form for them. But I guess that's just me.
I know that we all think that we write clean, clear, concicse code and that anyone who reads it will have no trouble understanding it. I hate to burst your bubble but when we are writing an app, we have so much internal information that simply never makes it into coments or documentation that those who follow in our footsteps are frequently at a loss as to why certain design decisions were made. Judicious use of comments helps (that doesn't mean you should comment every single line of code. Use common sense if you want people to actually read the comments and make sure to change them if the procedure's logic changes.). Sometimes documentation overviews help - assuming people actually read them but more important is using standards that will help people who come in cold, figure out what is going on. For example, it is important that you name your globals and TempVars and Form contols in such a was that the average reader can actually "see" their use and so be wary of changing them.
No argument there. If I write code to be maintained by someone else, I make a habit of commenting the correct use of the global variable in the special standard module I put them in. But in general I am convinced that code with globals is more readable and maintanable than one that relies on the use of hidden forms (or Windows API) to pass data.
Knowing he is dealing with a Global will probably give your successor pause for thought and he should realize that changing it could easily affect some other part of the app and so he needs to do some research prior to making any changes.
But, Pat, isn't that the case with pretty much everything? It may be an obscure column in a table; it can be a user-defined structure or object, it can be the use of an event. Why to single out globals? I don't know how you, but when I go over someone's code I don't start changing things until I feel reasonably sure I have solid grasp of what is going on. And actually, I have gone through professional work where all globals where prefixed with "g" or "gl" and placed in a separate module with other globals. So, against all the dire warnings of the naysayers, there is I believe a lot of common sense out there in using the globals.
Pat Hartman said:
Coupling and Cohesion are terms that predate OOP. Coupling describes the connections BETWEEN objects and Cohesion describes the connections WITHIN an object. The general rule is that you want procedures to be loosely coupled (not dependent on each other unnecessarily including passing very few variables) and highly cohesive (all the code within the procedure should relate to the same process). For example, you would never use the same procedure to write payroll checks and FTP your backups because both happen every other Monday. That means that Global variables which are not precicsely defined and correctly used can cause pathalogicol coupling causing procedureB to fail because someone made a change to a variable that was intended to benefit procedureA. I'm sure you've all run into a software bug and while scratching your head said, how the *** did that change cause that effect? The answer will very likely come down to the developer not understanding (or ignoring) the principles of coupling and cohesion. Keep in mind that very few applications go their entire productive lives managed by their original developer. This is why defensive programming is so necessary. Your goal as a developer should't be to be "elegant", it should be to prevent future errors if possible.
This type of argument against the use of globals is why I opened the post. To expose it as group-think or prejudice. It's an argument from "excessive design" that I have not yet seen supported by a single compelling example. Also, it is interesting to see you joining Mark and Galaxiom when you said this earlier:
Pat Hartman said:
]Some of you are taking this way too seriously. If I didn't know better, I'd think you were arguing about surrogate vs natural keys
So frankly, I don't think there is danger of "pathological coupling" from the use of global variables. I don't see any reason to label poor programming that way but more to the point, the globals in and of themselves do not present any more of a problem than say object variables. Maybe, there is more issues with the former but that would be because startup programmers usually don't do OOP. But bottom line: you don't prove anything by simply asserting something, especially not when you start from a false premise (i.e. that global variables include an invitation to programmers to use them thoughtlessly and/or in preference to a lesser scope).
Interesting that no-one has pointed out in the nearly three dozen posts here that Access is, for better or worse, a RAD tool. And yet nearly everyone would concede that globals are as a rule the simpler solution. Surely, there has to be some reason why Microsoft insist on leading us into temptation. (Worse even, the old "global variables" were extended into "public variables" in standard modules -A2003?- so you can now choose how to sin). But friends, I am done here so I won't speculate on what it is.
Thanks to all who participated here.
Best,
Jiri