RE: guidelines for abbreviating field names (was: Exempt/non-exem pt survey results)

["Carnall, Jane" <Jane -dot- Carnall -at- compaq -dot- com>]

Carolyn Davidson is >> included in the development meetings. One of the
areas where I think I can make a contribution is in field names, which are
clumsily and inconsistently abbreviated throughout.<<

This is frequently (according to my experience) a problem in clunky old
mainframe systems, because the developers simply abbreviated field names as
it occurred to them at the time, usually without the slightest regard for
consistency, style, or common sense.

>>Are there any guidelines for abbreviating field names? For example, even
if you have 4 spaces, I'd rather see CLAIM abbreviated as CLM than CLIM...
seems misleading to split a vowel pair. <<

I know of no formal guidelines (and would be interested to hear if you find
any), but the example you give demonstrates that *you* have a good idea of
what makes a sensible abbreviation. 

The system that I used, some time ago and on another project (in another
galaxy far far away) was as follows: (1) Compile an alphabetical list of all
the words that you know are abbreviated on your system. (2) Set minimal,
essential parameters (such as maximum length of abbreviations) (3) Ask for
volunteers - as many as you can deal with. Ideally, they should be users,
and definitely not developers, but you may be out of luck there. (4) Pass
out your list of words and the basic parameters to your volunteers, and ask
them to go quickly down the list, abbreviating each word in a way that makes
sense to *them*. (5) Collate the responses.

This gives you a baseline to work from. (Even a small number of volunteers,
say 4 or 5, can make all the difference.) After setting up that baseline,
you can use it to compile your own list of unique abbreviations and a firm
yet flexible set of standards and guidelines for new abbreviations as
required. Make that list available, update it regularly, and make sure you
have final effective authority over the field names since you will *always*
get developers who think the rules about abbreviating field names don't
apply to them. The list can be the basis for a glossary.

>>Also, is it better to drop letters (preferably vowels?) out of the middle
=
of the word, or truncate it? And would you use a period to signify that =
this is a shortened version of the word (which itself takes up a space =
that could be occupied by an additional letter)?  For example: ACTION =
becomes ACT. (vs. maybe ACTN)<<

Fix your own standards to suit your system's requirements. You might want to
distinguish between ACTING, ACTION, ACTIONING, ACCEPT... I would say as a
general rule that the longer word ought to have the longer abbreviation, and
pretty definitely that you either always use the period to indicate a
truncation or that you never do. What matters is consistency and uniqueness
- and a glossary.

HTH,

Jane Carnall
Technical Writer, Compaq, UK
Unless stated otherwise, these opinions are mine, and mine alone.