>>>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.
>
>This happens elsewhere too... in Hungary, ten years ago, they were localizing Windows, and decided that proper translation for "directory" (*) was "könyvtár" - literally, "book warehouse", ie. a bookstore or library.
>
>All was fine until they stumbled on some developers' tools... how do we translate "library" (dll, for instance) now?
>
>----
>(*) world "folder" was politically incorrect in Windows back then, as it existed only on Ataris and maybe Macs - thou shalt say directory and only directory always, and never ever mention the dirty word "folder"!

Dragan,

< vbg > One of the things some people (and I'm not pointing any fingers here except to someone I'm personally involved with), is that they don't understand the purpose of standards.

Standards exists for one, and only one, reason. To make the code more readable. Frankly, I don't give a flip what convention is used as long as the code is readable.

Some folks, however, see it as a chance to micro-manage the development process. This practice is, of course, a very bad idea since software development by its nature is a creative endeavor. Creativity and micro-management don't play well with each other.

What follows is true, and I'm stil involved with this issue.

I was give the job to write an SQL Server Stored Procedure that would sum up weekly production for the various plants that Shaw has. The source table had a field named "square_yards". As a result, I used that field name in the target output.

A couple of weeks after the job was finished, and a number of dependecies were created, I got another assignment. Bring the field name into the current standard. What violated the current standard, in this case, was the use of the underscore character.

Next week, I'll take on the task of trying to convince the "PHB" that: 1. Eliminiating the underscore does nothing to increase readability, and, in fact, may make it less readable. 2. That since readability isn't going to be improved, there's no reason to take on the risk of breaking working code.

Frankly, I'll be surprised if I win this argument. I couldn't convince the same individual that Windows stores file time stamps as UTC time with a ton of documentation to back me up.