Hi Peter,

[SNIP]
>But do you think it would be good idea to propagate to the community the idea of g as demonimator of public variables AND variables declared private in the main program? That was my question.

I have no objection to using "g" as a standard for global scope. I already use a similar method for variables to designate their scope and data type anyway. I would probably be more inclined to continue using the _underscore to further designate public/global variables such as m._gcCompanyName or m._goAppObject.

Whatever method you use, it is important to document it and be consistent. It is especially important that everyone working on an application is aware of all global variables and what they are used for and to forbid creation of global variables on the fly. Before a global variable or public variable is created, you should first look into the problem which requires it and if it makes sense to use it, document it.

Most problems associated with public and private variables can be avoided by proper declaration of every variable that is created. Explicit variable declaration and strong data typing would be something that the VFP development team could do to help with this. The EXTERNAL command could be extended to include EXTERNAL VARIABLE List... to declare variables that were created in other procedures, and enforce declaration of all other variables as public, private or local. This could be done with OPTION EXPLICIT like in VB to allow this additional programming constrant, while allowing legacy code and those who do not want to use it to run without it. This would go a long way to reduce careless, sloppy programming that causes most problems with variables in the first place.

Just my additional 2 cents.