Re: Naming Convention for Columns

From: Frederick Rust, IntraNet, Inc. <frust_at_giant.intranet.com>
Date: 1998/03/10
Message-ID: <1998Mar10.134126.18779_at_giant>#1/1


In article <01bd4b10$21e41e80$7387d9cf_at_rana>, "Alvin Sylvain" <alvin_at_NO.JUNK> writes:
>
> The main problem in naming conventions this way (ie, using "shortcut"
> names) is coming up with unambiguous shortcuts for everything (because
> the guy who came up with the idea is fairly lazy when it comes to
> typing)
> vs. words that are "long-enough-for-any-idiot-to-understand."
>
> What you have to do, and what we did, was create a "glossary" of
> "company accepted" shortcuts. Naturally, the only person who read
> and followed this glossary was the guy who wrote it. (I mean, come
> ON, already: changing a perfectly understandable "FLAG" to cryptic
> "FLG" in order save one character? Is it "DT" or "DTE" or "DAT"
> instead of "DATE"? All this confustion just to follow this
> "consistency" bug-a-boo?)
>
> So, in other words, in order to follow this new naming convention,
> we all had to learn a new "vocabulary." On top of all the other crap
> we had to learn (we were proficient in Sybase, but the customer wanted
> Oracle).
>
> My personal preference is for self-documenting variables, including
> table and column names, using shortcuts only where necessary. Of
> course, you still have the problem with ambiguous and multiple full
> spellings of words, but I think that problem isn't anywhere near as
> severe as that of the utter *reams* of possible shortcuts for words!
>
I agree, but want to point out that long descriptive names have analogous problems -- e.g., is it "Account_Last_Updater_Name_ID" or "Account_Last_Updater_IDname"; "Credit_Account_Number_Suffix" or "Credit_Party_Identifier_Suffix", etc.

In some ways the old-time naming restrictions (e.g., eight bytes for a variable) imposed a disipline -- you made sure you read and wrote them correctly! Received on Tue Mar 10 1998 - 00:00:00 CET

Original text of this message