>SNIP
>>
>>VFP10 could also presume LOCAL if a variable starts with the character L, either lower case or upper. In a same vein, the character P would indicate that it's a private variable, and so on. Moreover, it could presume the datatype by analyzing the second character. In other words, starting with VFP10 we might no longer need to explicitly declare LOCAL variables on top. The advantage is not applicable to private, global and public variables, however.
>>Furthermore, there could be two views for code. In view 1 variable names are shown entirely. In view 2 the first two characters are hidden.
>
>It better NOT do this < s >.
>Some of us HATE that "Hungarian notation" crap! And with more than 10 characters now available, who needs the crap anyway????
>
>I've seen more than 1 guru here say that they write magazine articles using Hungarian solely because of the limitations imposed by print (very limited width). I know, I know, that doesn't mean that they do not use Hungarian, but I bet it's true in at least some cases.

Well, first of all, true hungarian notation is more complex than what I used in my examples. But I imagine that it'd be fully customizable. Position 1 and 2 for datatype? Positions 3, 4 and 5 for scope? Fine with me. Scope not limited to l, p and g? Three-letter strings (cnt, cmd, etc.) indicating the type of control? Modify the table and voilà, auto-declaration and optional hiding of these technical parts in the name should work fine.