>I have to defend myself... :) Although I understand what you're saying (this message and others) and I also agree up to a certain point. :)
>
>There's an important difference between variables declared as PRIVATE and variables that are not declared.
>
>When you're saying (and others) that undeclared variables are by default PRIVATE, than everybody understands that a variable declared as PRIVATE is the same as a variabled that is not declared before being used. And this is true only if the same variable doesn't exist at a higher level. I won't discuss everything again here. You explained it very well in this thread...
>

Revise the statement - a variable that is not explicitly declared for scope within the current procedure/function/method first (for the remainder of this message "block of code") checks to see if the name is resolvable in the current scope, if so, it uses the currently visible variable matching the name. If it does not find an instance of the name in scope, it creates a PRIVATE variable which is visible to things called by the current block of code, which will be released when the current block of code finishes execution.

A variable declared explicitly as PRIVATE will hide any use of the name by a preceding explicit or implicit declaration as long as it lives.

The PRIVATE statement also has the ability to hide the scope of variables declared previously according to a skeleton (PRIVATE ALL LIKE/EXCEPT skeleton) to prevent anything from higher levels from being MUNGed by side effects. It does not have to explicitly declare variables, it can prevent previously declared variables from being visible. This is the whole idea in using the name standard of treating any variable beginning with j as a "local" by adding PRIVATE ALL LIKE j* in all procedures/functions under 2.x - it gve us the ability to emulate LOCALs by having an always-restricted range of names within a block of code. This provides a mechanism for implicit restriction of downward visibility.

>All I want to say (and wanted to say in previous threads) is that an undeclared variable may introduce behavior that is different from the behavior one has with explicit PRIVATE declarations.
>

It's necessary to allow things that might be passed down inferentially as GLOBALs or PRIVATEs to get handled according to scoped visibility and changed through side-effect alteration. If a variable is created by VFP without a prior declaration, it is declared as a PRIVATE variable in the scope of the current block of code. If a variable that is not declared explicitly or implicitly in the block of code prior to its first reference, the name table is checked to see if the name is currently in scope and visible; if it is, the currently visible name reference is used, otherwise, a new variable is created with PRIVATE scoping. Does that state the situation adequately?

>Or, more clear, declaring a variable as PRIVATE in a proc/func/method may change the behavior of your application. This is why an undeclared (at a certain level) variable is not exactly the same as a PRIVATE variable.
>
>And this is the point to this discussion: whatever you do, explicitly declare all your variables using LOCAL, PRIVATE or PUBLIC (why and when to use each is a different thread :)).
>
>Vlad
>
>>I'm sorry, but Paul is incorrect on this one. Private is private is private and there are no variations on private. Variables created without being delcared are created as private variables. Assigning a value to a variable is not, necessarily, creating the variable. Depending on the assignment of a value to create a variable is a bad practice (but that doesn't change the simple fact that private is the default scope for variables in VFP).