Peter,

I'll take one point at a time.

First the only thing that declaring a variable PUBLIC gives you is that the PUBLIC variable will outlive the program it is created in. Therefore, the only reason to delcare a variable PUBLIC is because you need it to outlive the program it is created in. The only reason you would need a variable to outlive the program that created it is if some other program, not lower in the calling stack, is dependent on that variable existing and that other program does not create the variable. If a program is dependent on a variable that is not created within it self or a program that calls it, there is a serious design problem.

Secondly, the potential problem for use PUBLICs in exes that at some future time you may want your EXE to be called from some other EXE and your publics are potential problems for the calling EXE. Also for some situations with DLLs that are sharing a runtime public variables can cause conflicts.

The real problem with PUBLIC variables is that they almost never cause a problem when they are first programmed. The problems come later long after you have forgotten where these vars are created.

My opinion is, has always been, and will always remain that there are a very small number of very specific situations where a PUBLIC variable is needed. In all other situations variables should not be declared PUBLIC.

Also my opinion can be strong and still be humble. Humility has nothing to do with how strongly I believe in my position, it has to do with how strongly I believe that others are entitled to their own opinions.

And in response to your other comment about the responsibility I spoke of, there are always new programmers looking in on conversations and we, as experienced developers, have to remember that the thinking process we may go through before reaching a conclusion and taking an action is not the same as that of a newer programmer. I have spent a good deal of my carreer teaching and that has taught me that new programmers do not think like experienced programmers. I can tell you stories of new Fox programmers talking about "never use macros because they are slow", "create indices on every field because Rushmore is fast", "always use SQL SELECTs because they are better than xBase code", and on and on. Every one of these quotes is taken from a new programmer (mis)quoting what they heard an experienced programmer say.