Hi Peter,

You wrote:
>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?

If you read my rather lengthy 2 cents worth, I can't see how you would conclude that I am one who "blame bugs on the mere existence of PUBLIC and PRIVATE." In my last paragraph, I freely admit that I still use public variables in a few instances. I was only pointing out that public and private variables can be troublesome if not used properly.

And I think that I would blame the programmer for being careless if he indiscriminately issues CLEAR ALL in a program or if he CREATES (or thinks he is creating) variables in a procedure without first declaring them either private or local.

If a public or private variable already exists with the same name, 
declaring it private or local allows you use the same named variable 
without affecting the value or data type of the pre-existing variable 
when the procedure exits.

As far as setting a standard that all variables beginning with "g" should be considered global/private, you can set your own standard and do that now with the existing VFP. Just document it as such and use it. Personally I use the _underscore before a variable name to indicate that it is a global variable (public or private). And as stated in my original post, '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.' I use a few global variables as a sort of extension to the standard VFP system variables.

If anything, I would like to see explicit variable declaration and strong data typing that would not allow changing the data type of a variable once it has been declared. This would prevent some of the the careless programming and associated problems that I have seen with (ab)using variables (public and private).

As for your example,
>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?!

I would not draw the same conclusion. My conclusion would be that it was careless or sloppy programming. The programmer did not cover all cases and introduced a bug.

Something like this is more my style.

LOCAL lcMsg
  lcMsg = iif(type("this.value") = "L" .and. this.value = .t.;
          ,"Yes, it's true.","No it's false")
WAIT WINDOW lcMsg NOWAIT

or 

LOCAL lcMsg
if type("this.value") = "L" .and. this.value = .t.
   lcMsg = "Yes, it's true."
else
   lcMsg = "No it's false" 
endif
WAIT WINDOW lcMsg NOWAIT

or 

LOCAL lcMsg
if type("this.value") = "L" 
    if this.value = .t.
        lcMsg = "Yes, it's true."
    else
        lcMsg = "No it's false" 
    endif
else
    lcMsg = "Invalid value" 
endif
WAIT WINDOW lcMsg NOWAIT

To make it clear, I have no problem using public, private, or local variables. They are included in VFP for a reason, perhaps just legacy code or perhaps because with proper application, they can solve some programming issues. I think that the key is proper use and declaration of all variables, comment your code and document what you do and why you do it.