>>However, if "it ain't readable, it ain't maintainable". The biggest problem that I see with such conventions is that they can lead some "pointy headed manager" into enforcing them simply because they can. Readability should be the deciding factor.
>
>And the best intentions...

Or "...the best laid plans..."

>I've had two cases back in 10-character field name times... "VrAna" was supposed to be shorthand for "VRsta ANAlitike" (type of analytics - which is an accounting category), which was all fine until I saw it again months later, and couldn't immediately guess what I meant, because "vrana" means "crow".
>
>The other one was "SumPor.dbf" (suma poreza - total of taxes)... which actually means "sulphur" :).

Well, the 10 character limit on the field names and variables is bound to cause problems in previous versions of Fox.

My rule is that I don't abbreviate unless the abbreviation is a standard. For example, KB or MB (for kilo-bytes or mega-bytes). However, the pointy headed boss type can often overrule you and make decisions that can cause more work than is necessary.

I've had this example recently. 100 cubic feet is abbreviated commonly as CCF. Rather than store the value in a field as something like "ConsumptionCCF", the choice was made to name and store the field as "ConsumptionCubicFeet". This meant that before the value is displayed to the user (in the case of editing) or adding, the value has to be modified prior to display and modified afterwards.