I'd like to raise a flag on those variable namings.

There is a term that I use in some situations that I have seen many many times, it's what I call the "Big Red Bus Syndrome" (I thought everyone knew it, but I just moved to a new city where no-one's heard of it before).

Basically it's where one or two key people can disappear overnight (eg; get run over by a big red bus) and effectively bring production in their area to a complete standstill.

I would suggest that using variable names like those you suggested, even where the current programmers know what they mean, can make the code unreadable to others who have to come in to support the code tomorrow.

Would you even know what some of these meant in another two years if you were working elsewhre in the meantime and asked to return to your old department to fix some of your old code?

Steve

>>Nope. These are unforgetable and may be obvious to you. But they are not obvious to the programmer that sees the code for the first time.
>>
>>Vlad
>>
>>>A good exception is the abbreviations which are unforgettable; look at these:
>>>
>>>indi_ana - indicator of analytical record
>>>vrana - vrsta analitike (type of analytics - but "vrana" means "crow")
>>>sumpor - suma poreza (sum of the tax - but "sumpor" is "sulphur")
>
>Ooops - I meant they're good as inhouse exceptions; all the programmers involved know the story and that's what makes it OK. They are well commented, also; but now I see it could have sounded as if I meant as recommendation for a general rule, which it surely was not.
>
>Anyway, I can afford one or two things like this from time to time; being a three man shop it never costs us more than ten minutes of confusion once a year. The standards I've set are not as strict regarding naming conventions for variables; field names, source formatting and commenting are a different story, so having a little fun is the best I can do for them (aside from paying them better, which is beyond my programming skills).
>
>It really was a long week.