Hi Elmer,

The quest I was raising was not whether/when usage of such variables is wise. I'm trying to find out whether we, as a community, can reach consensus about declaring g-variables as private. The vfp-doc calls only public variables global.

But, reading your well-written reply, there's another thing that comes to my mind, although it should have a thread of its own. How about the next piece of code:

LOCAL lcMsg
IF this.value = .t.
   lcMsg = "Yes, it's true."
ENDIF
WAIT WINDOW lcMsg NOWAIT

As you'll probably notice, it's buggy code, for lcMsg won't get declared properly if this.value is false. Conclusion: We should avoid the usage of IF, for it introduces buggy code practices! Right?!

No, of course not right. You realize that with regard to IF. Why do you and many others blame bugs to the mere existence of PUBLIC and PRIVATE? Why not blame CLEAR ALL? Why not blame the programmer for being careless?

Regards,
Peter

>Hi Peter,
>
>Public variables, private variables as well as "global" private variables declared in your main program can be troublesome, especially with sloppy programming where variables are used but not specifically declared local, or private. When a variable is declared as private, if a lower level procedure uses a variable with the same name (without declaring it local or private), and the lower level procedure changes the value or worse yet, changes the data type, the calling program that originally declared it may have problems that may be difficult to debug. With public variables the above statement is true not only for lower level procedures but anywhere after the variable is declared public. Additionally, if you attempt to declare a variable public after it has already been declared local or private, you will get an error "Illegal redefinition of a variable".
>
>IMHO, any problems associated with using either public or private variables can be resolved by proper declaration of EVERY variable that is created in every program as local or private and by proper DOCUMENTATION and testing, DOCUMENTATION and testing, DOCUMENTATION and testing...
>
>I have had far more problems with violations of what I (and apparently George Tasker) call MOM's rule. That is the rule which states that "You should always leave things as you found them." If you need to change a system setting, check its current value, set to what you require and set it back when you are done. I cannot tell you how many times someone reset "Set exact" or "Set Deleted", "Set Default" or "Set Index" ... in a function without resetting it back which caused unwanted effects in another place. Problems caused by this are equally difficult to debug as those caused by changed values in public or private variables. Although it normally does not cause problems, the one that irritates me the most is "Set Talk".
>
>Local, private and public variables (as well as "global" private variables declared in your main program) will cause problems if CLEAR ALL is issued anywhere. They will all be CLEARED. This will generate errors in any program which has dependencies on specific variables being defined. I normally only issue CLEAR ALL on closing the application which releases all public, "Global" private, private and local variables.
>
>RELEASE ALL called in a program will not release public variables and will not release private variables that were declared in an upper level program. RELEASE ALL will release local and private variables declared in the program in which release all is issued.
>
>The problems that I see with public variables...
>1. They persist after the calling program that declares them.
>2. They can be changed by any program which may set a value to it (if the program does not first declare the variable local or private).
>3. Clear all issued in a program releases them (usually at inappropriate times)
>4. Changes to a value or data type can cause unexpected problems that can be difficult to locate.
>5. Makes it difficult for other programmers, or even the original programmer to work on the code after the variables are long forgotten.
>
>The same can be said for private or "Global private" variables (with the exception of #1.)
>
>I've heard it said that public variables cause problems in other VFP EXES on the computer. There should be no interaction with a public variable and another VFP exe UNLESS the second EXE is called from the first and is running in the same environment space. So if your VFP EXE sets public variables, another separate VFP application started from Windows will not "SEE" the public variables declared in the first exe if each one is running in its own environment space.
>
>I do still use a few (well documented) public variables to hold certain information that is global to my applications such as user's registration information, file paths, etc. These could just as easily be "Global Private" variables, but they are stored in a table that uses a UDF to declare and set them, which makes it possible to issued clear all and re-run the UDF to restore the public variables that I use from anywhere in the program such as an error handler that returns to main. These "Public" variables are used and treated much like "Reserve words" like "_pageno" and "_tally" in VFP. They are very well documented so that everyone involved is aware that they exist and how they are to be used. The only problems that I have had with public or private variables has been caused by variables (not properly declared in a sub procedure) changing the value of a previously declared private or public variable.
>
>Just my 2 cents.