>I read back across the thread of this message -- lots of opinions. Yes there is bad VFP code out there written by people with poor practices and there is good VFP code out there written by people with better practices. Hard-coding values is bad practice in any language. I see bad practices in other code languages besides x-base. But why complain about it when you cannot change the other coding practices; especially, if you have now inherited it? What does it accomplish?
>
>I work in SAP as a consultant and see lots of hardcoding in ABAP code. Changing to a table driven derived value is always preferred that is done by configuration. Agreed, hard-coding names at each step of access is very bad; better to have a permissions configuration. But again why complain? Just grunt on your own and fix it. The fix may be piece-meal since the owner may not want to pay for a complete rewrite; sometimes you are lucky and can fix it throughout the program. Most of the time I am directed to just 'piece-meal' fix to the localized place causing the immediate concern.
>
>To me the x-base language is very sloppy -- Fox Software in creating FP should have 'cleaned' it up (or at least Microsoft when they created VFP 3.0 which was headed up by Dr. Dave at the time). Why allow a variable to be used that is not declared with a specific data type? Typos allow a variable to be defined on the fly and then have to be debugged. Having the variable change data types any time in code can be a nightmare. The PRIVATE notation is especially bad -- allows a variable in a program to be changed by a child program without it being passed by reference; try to debug this behavior to find a bug. Why is a table-field reference allowed to be only by the field name; I think it should enforce the alias.field as a way to access a table field value (BTW - I think it should be alias~field or some other separator that is not a period '.' since this is used in objects). By allowing a table field to be accessed solely by its name caused the need for the m.dot notation -- what a 'pot of crap' this created. These are a few of the 'crappy' parts of VFP/x-base coding.
>
>But VFP is what it is. Now the developer has to have a set of rules to try to eliminate these 'short-comings' of the language. I would welcome Chen's VFP 10 to fix these short-comings and turn VFP into a more strict language with enforced data types and access to table field values.

The problem is when I have been harassed and bullied by one particular individual for years. Every time I explain that mdot is hard-wired into FoxPro and how it has been absolutely necessary because of all the crap code I've inherited. There is a point where the line is crossed. Calling Koen's 2 lines of dbase 3 code crappy is not a sin, but toxic humanity is. I've had many good discussions, including one with Andy Kramek which earned my the Microsoft MVP - and I was proud of that because I could discuss things rationally with one of the best. I am not wasting my time on this community which like all groups of humans consist of a few experts and a bunch of slugs.