>>Here's the beginning of a list of commonly misused and abused features, functions, and commadns fo VFP.
>>2: SET FILTER TO ... is very often used where another construct would do the job much more efficiently and with better performance.
>You're right - but it gets a class room projects completed!
And you can start up the charcoal grill by tossing on a gallon of gasoline and dropping in a match. QUAD has advantages when doing a sloppy job doesn't matter.
>>
>>3: & the macro expansion feature is too often used where it is either not necessary or ther is a bettter way to accomplish the same goal.
>But it's powerful - it's save me miles and mile of "IF" constructs, but I try to pass by reference, when I can.
>
And 99.7% of the time that it's used, better and faster alternatives such as name resolution and EVAL() are available. The fact that I can pound in a nail with a brick doesn't make the brick a better tool than a hammer. Knowing when and where macro expansion is, and equally importantly, is not, the best solution would reduce the time certain people spend scratching their heads because something has a space or other delimiter they hadn't anticipated in it.
>>4: Filtered indexes, are often used where they are not necessary. The same result can be obtained using SQL without the overhead of having an extra index tag around all the time.
>But SQL is slow - why normalize if you SQL?
SQL is not slow compared to xBASE syntax, except in carefully-crafted situations where the programmer can anticipate the retrieval requirements of the system, in which case, SQL can still beat it easily with a little forethought, or an intelligent backend that can learn from patterns of retrieval what sorts of changes to make to enhance system performance. Normalization reduces risks such as update anomalies and clarifies the interrelationships and dependencies of data elements for retrieval and future modification. SQL offers portability and scalability. The two complement each other well.
>>
>>5: UNIQUE indexes, not only are they misused but they could easily be totally removed from the product without any alteration in capabilities.
>I don't think so - this guy helps when you have the same child key associated with differnt parents in a time line. If you need the childs history - you don't necessarily need to see the detail for the child for every parent.
>
No, this indicates that you haven't properly identified the relationship between entities, and specifically the primary key's dependencies on time elements in the 'child', and perhaps the direction and scope of the relationship. YMMV. Again, you can do things wrong and get away with it, it doesn't make them less wrong.
>>6: PUBLIC variables are often used in situations where they are totally not required.
>Tru - but there great for trace routing and testing.
Again, it's a matter of opinion. PUBLICs create far more trouble through unanticipated side-effects than they solve, at least for me. I find it more convenient to use other things like parameter objects as a means of communicating back new things to the upper reaches of the application environment. You can pass object references around just as easily.
About the only place I use PUBLICs at this point are as a means of implementing static class properties - the first instance creates the PUBLIC, and all instances share and update the PUBLIC variable. This can usually be avoided by creating an object factory - an object used to create instance of other classes. If the factory has a lifespan greater than that of any objects created by it, it can hand each instance it create a reference to properties contained in the factory, and the shared reference is visible as long as the factory is visible. This has the added benefit of offering a control mechanism for the shared property - the factory can provide semaphore and MUTEX mechanisms easily via ASSIGN and ACCESS methods. If it ever becomes necessary to make the static available across multiple systems, the factory can implement something like a shared table to provide the storage without affecting the client class.
The fewer PUBLICs wandering about, the happier I am. My programming style would probably annoy you to death.
>>
>>7: SET EXACT is often used to cover for not understanding the way strings are compared in xBase. This causes the loss of a lot of functionality that is inherent in the product in order to adapt to a lack of knowledge.
>Yes, but its great when you need to instance partial keys!
>
Again, there are alternatives. I think we can sum this up as I'd not be happy inheriting your code, and you'd find mine equally distressing.
