Evan-

>Jim, could you provide alternatives to these?

You asked Jim, but if you don't mind my $.02 U.S....

>>1: Inheritence has to be the single most commonly misused feature of all OO languages.

Depends on how it's being misused. I'll let others field this one, since I probably abuse it.

>>2: SET FILTER TO ... is very often used where another construct would do the job much more efficiently and with better performance.

P-views, SET KEY, manually navigate thru records matching the key, strategic indexing (probably not so necessary anymore).

>>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.

Use named expressions. Use EVAL().

One of the odder named exp. that works (IMO) is:
STORE "hello World" TO ("myTable." + cField)
instead of
myTable.&cField. = "hello world"

One place you need em is to build a RUN expression. I don't know of a way to get around the macro there.

>>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.

Ugh. For primary indices, use surrogate primary keys.

>>5: UNIQUE indexes, not only are they misused but they could easily be totally removed from the product without any alteration in capabilities.

Ditto for #1.

>>6: PUBLIC variables are often used in situations where they are totally not required.

Use an application object. Must admit formsets make convenient application objects for this reason. Otherwise, the ONLY public variable I might define willingly is my oApp.

>>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.

I usually see the opposite...people untrimming variables (that may or may not need it) and then using ==. Personally, I don't care if people prefer SET EXACT ON or OFF. Honestly, this is one of those help topics that I have refered to alot, just because I can turn it around very easily (like cstr1 $ cstr2 )...it's just a mistake my brain is prone to, so I like SET EXACT ON.

>>8: == is often NOT used where it should be. See SET EXACT above.

Or used "just in case."

>>10: PACK is too often sued in situations where any benefit it porovides is far outweighted by the costs associated with it.

Recycle deleted records. Or just ignore them except for periodic table maintenance.