Would enjoy hearing comments on the following controversial? strategy for declaring local variables.

Disclaimer 1: The following strategy is the result of VFP not supporting an option that requires explicit variable declaration. If VFP had a compiler option that enforced variable declarations (like VB's explicit variable option), I would enable this option, explictly declare all variables, and the rest of what follows would be a mute point.

Disclaimer 2: I am aware that VFP 7 has the _VFP.LanguageOptions feature that can detect undeclared variables at runtime. However, this feature is dependent on the code path being exercised by a particular application run. Given the large number of possible code paths in even a simple application, this feature provides a very narrow (almost worthless in my mind) ability to determine undeclared variables.

OK, on to my conterversial question ...

In our global include file we have the following definition:

#define LOCAL_ALL private all like L*

Then in ALL our function, procedure, method and event code we place the following line immediately after any lparameters/parameters statement (or as the first line of a code segment without parameters)

LOCAL_ALL

We use a standard form of Hungarian notation that begins all local variable names with the letter 'L'. The net effect, as I see it, that any variable we reference in our code will technically be 'private' (i.e. visible to other functions deeper in the call stack), but, pragmatically speaking, will actually behave like 'local' variables because any identically named variable deeper in the call stack will have its own 'local' presence due to all code having the LOCAL_ALL statement in its header.

I see two advantages to this technique:

1. Code robustness: This technique guarantees that all 'local' variables (i.e. in our convention, variables beginning with the letter 'L') will in fact be *invisible* to all other functions. The problem I see with explicting declaring variables using the 'local' statement is that missed variable declarations (or declarations where the name of the declared variable and the variable actually being used are different, i.e. a misspelling or unintentional letter switch) will result in the variable in question becoming a private variable. Without warnings. The private all like L* technique serves as a safety net that prevents these type of variable mis-declaration problems from slipping through.

2. Code that is faster to write and easier to read: By faster to write, I mean that we don't have to go through the manual process of declaring basic data type variables (integer, char, boolean, etc.) because our Hungarian naming convention 'automatically' documents a variable's data type. When using VFP 7 we will manually declare variables of specific classes to take advantage of Intellisense when needed. By easier to read I mean code that is not cluttered with tons of obvious variable declarations where the basic data type is known/implied by the variable's Hungarian name. (I recently saw a 3rd party VB/C++ editor - can't remember the name - that gave one the option of hiding certain types of code including comments (and comment types), variable declarations, and #if/#endif blocks, etc. I was impressed with how this type of option could improve high level code reviews vs. code editing)

In summary, I understand the value of explictly declaring variables when the compiler has the ability to detect undeclared variables or variables whose use will result in type conversion problems. And if VFP had such an option then I would use it. But since VFP doesn't have such an option, the value of explicting declaring variables 'just because its a good thing to do' doesn't make sense to me and in fact seems dangerous given the fact that missed (mispelled) declarations result in the creation of unintentional private variables subject to all the side effect problems of global variables.

Any comments appreciated.

Malcolm