>>The point is to teach best practices.
>
>Well, I think you know that I not only agree with you about the use of public variables, I think you also know I go one or two steps further: no PRIVATE variables and no PUBLIC properties either, any changes in the state of an object should be accomplished by sending a message to it, never by assigning a value to a property (which should be protected anyways, or even hidden).

I know most of the arguments for getter/setter methods (or messages) in Java/C# land, but for me - unless special functionality is needed on a specific property - vfp access or python "property method" is the better way to operate, as it eliminates boiler-plate code having no *special* purpose. Have automatics for the rule and code the exceptions is my mantra for OOP. Even automatically or with minimal effort created code will be read or sometimes traced in the debugger (C# get/set close to being good/terse enough for me) . I am with you on not opening up every property used in inner working of a class, but any open (in the sense that it is part of the interface) property does not need a special method/message *for me*.

Utilizing top-level variables makes it often easier to port special functionality across projects of different developers/clients. For me logging and performance measuring are prime examples - between a handful and a dozen such toplevel variables - themselves objects - should be fine - if the number reaches 2 dozen, it is for me a signal to check if refactoring is needed. Creating a toplevel variable in sublevel code is for me most of the benefit of public.

Private is useful in some circumstances like the example of SQL parameters or when creating a common subset of variables for some time critical code as passing the variables is time consuming in vfp - it is against the knowledge of better practice and has in our environment the MUST of 3 times the amount of comment describing the need for going against convention. Enough for me most of the times to look for other ways ;-)

Keeping an OPTION to use all features of a language IMO is a benefit. Dogmatic prevention makes for sometimes ugly code - in my book it is better to allow going against better practice rules in certain special cases, but make it painful enough for the developer so that it stays the exception from the rule. And the autor of such parts must make it clear WHO was responsible for going against common rules - no hiding in obscurity or group identities in SourceSafe.

So while I am with you and Mike in thinking that normal code is better with minimal part of the debug screen full of non-local variables, creating dogmatic boundries is worse than allowing such practices to enter 5% of the code with 15-20 percent of comments centered around it.