From: jfr@RedBrick.COM ()
Subject: NO NUMBERS! (or even SHORT INTS!)
Organization: Red Brick Systems, Los Gatos, CA
Date: Mon, 28 Sep 1992 00:34:21 GMT

(This was posted before but got routed to the wrong news group - in fact
 it was routed to news.groups :-) so I am reposting it where it was 
 supposed to have been posted in the first place.  If it goes astray
 again, PLEASE DON'T E-MAIL ME 1000 times, thank you, jon :-)
 
We were recently stung by an interesting bug in a program that fortunately
was fixable instantly but got me to thinking.  The bug was simply the
misuse of a short int (16 bits) where a long int was needed.  This caused
the output of a set of data to be restricted to 32767 rows, even if there
were more rows in the set.  This happened quietly so it had not been
noticed until a fairly rigorous test suite was run.  In any case we fixed
it easily and that is no longer a problem.

The problem I started thinking about is WHY IN THE WORLD WOULD ANYONE
USE SHORT INTS IN A PROGRAM, particularly one done for a workstation-level
machine (i.e., large memory model, etc).  I can see the need for memory
conservation to some degree, but certainly there is no performance
benefit on most machines today (there may even be a performance penalty
in obscure cases).  I can also see the need to store short ints on disk
for databases since memory can multiply radically when you have large
databases.  But for in-memory structures, particularly counters and indexes
and thinks like that, there is simply no justification to use short ints.

In a related conversation, someone mentioned that many organizations have
coding standards that let them redefine the size of ints to keep this
from happening.  For instance use int1, int2 and int4 as typedefs and you 
can make them whatever you want.  This is where the thought struck me that
makes me curious to get other peoples' opinion on.  Why would you EVER
use NUMBERS in a program.  Except in TWO places: inside quoted strings
and on the right side of #defs (or the equivalent depending on the
language).  There is no justification for using a number in a variable
name or typedef or whatever.  The above example should be vsi, si and li 
or shint, regint, lngint or something like that.  JUST NAMES, NOT NUMBERS.
Why?  Because using numbers causes a confusion in the event that you 
decide to change the platform or the concept.  It is fair to say that
a lngint must be equal to or longer than a regint, but I contend it is
erroneous and misleading to say that an int4 must be EQUAL TO or longer
than an int2.  Longer than, maybe, but EQUAL TO?  That is just wrong.
In fact, int4 and int2, by normal thought processes, expresses an exact
2:1 relationship.  And the fact that I can change that in a hidden way
does NOT make things clearer, it makes things muddier.

So I suggest a coding standard: numbers should be barred from use in
variable and type names.  Only letters can be used.  Numbers can only
appear where you define manifest constants (#def, const, etc.) to 
names and inside strings (where they generally do no harm).  

Any comments?

Jon Rosen
jfr@redbrick.com
-----------------------------------------------------------------
"Where is the wisdom? Lost in the knowledge.
  Where is the knowledge? Lost in the information." -- T.S. Eliot
"Where is the information? Lost in the data.
  Where is the data? Lost in the #@$%?!& database." -- Joe Celko
-----------------------------------------------------------------