>You could not be more wrong here. Do you happen to know the complete hungarian notation. What its inmediate purpose was. How it is to be ported to the VFP platform ? Do the same motivations and rules apply to the VFP platform ?? How many versions of hungarian notations are out there ??
>
>There is simply *no* one standard for hungarian notation on the VFP platform.

Not sure how any of this matters. I'd say a working set of guidelines evolves and even if it varies slightly from programmer to programmer, the benefits are still gained.


>Because hungarian notation bring problems in readability also (lnAccountNumber can be easily read as In - Acount Number, and confuse people. No matter how hardcode programmer you are, you can read plain english way easier than hungarian notation and therefore at least my brain can get confused with hungarian notation).

Use a font that clearly distinguishes between the letter i and the number 1. I've been using Andale Mono for years. The error you mention only happens in the beginning for a programmer new to the standard. When I moved to hungarian and went back to revisit old code, it made a huge difference in readability (as opposed to revisiting old code where before I had used the convention). It was like night and day.

>I agree with Jim, If they cannot find out by looking at the code, they should be looking for another job. It is knit picking. Esspecially since we are able to specify the type of a variable in code (eg. LOCAL MyVar as Char)

You guys are missing the point. It's not a matter of work ethic or know how. Rather, it takes time to look things up. Time is a scarce resource. Small bits add up over the course of a project. Further, it becomes more important when you are working on something with complicated logic and you are trying to keep straight the variables you are using. Yet another example - I don't use private vars very often, but when I do the scope designator is beneficial because the variable may not be declared in the routine I'm currently editing.