>>>>That does not mean use every tool. Name one time where public is the most desirable.
>>>goApp.
>>
>>I wonder if that is necessary to declare goApp as PUBLIC. Private would work as well, when
>>goApp is instantiated in the main.prg before READ EVENTS, at least that's what I'm doing now.
>
>
>It has the same effect as being PUBLIC when created from the top level program. Many designs do not put goApp creation in MAIN.PRG, but in a called class or procedure.

I believe this is a bad practice, but this is my personal opinion. If a variable is PUBLIC, then the programmer must assume that this variable is available at all times. Otherwise it would not be public. If you declare the public variables at a point in time later than main.prg, you can fall into the trap to add later functionality or reuse code that makes use of those public variables, and call that code before the variables are declared. There is not a practical way to properly document this in the code and it can create program errors that are very difficult to trace.

>A couple other reasons to use PUBLIC variables are:
>(1) To prevent the requirement of passing "constant" parameters (that don't change during the course of the repeatedly called function (as in recursion), but are dynamic based on the startup / runtime environment when called)

I personally also don't use "constants" anymore. I rather create classes with the properties and make them available in a singleton object through the goApp object. Proper use of assign methods and access methods help to prevent changing of the properties and intellisense helps avoiding typing errors. Constants are outdated and I'm glad I never really used them, unless a third party tool asked for it.

>(2) To prevent the need for initializing variables within a oft / repeatedly called function

Again here you can create objects that are instantiated at the beginning and when passed as parameters they will be available in the repeated function calls.

>Visual FreePro bypasses #2 by a new LOCAL PERSIST keyword, which retains the prior value on subsequent function calls by that thread.
>See: http://www.visual-freepro.org/wiki/index.php/VXB%2B%2B#LOCAL_PERSIST_Variables