Julia Thompson <[EMAIL PROTECTED]> wrote:
> And sometimes it's not a number, it's > a text string.
> Some programmers don't seem to realize > this. At least, some programmers writing > code for programs at the university I > attended didn't at some point. It's > annoying to have the grade report arrive > a few days late because the zip code was > treated as a number when you (unlike most > of the attendees) live in New Hampshire, > where all zip codes start out "03". (I'll > spare everyone the similar rant about Social > Security numbers being treated as numbers > rather than text strings. Just assume > there is one.)
That programmer was definitely smoking something if he forgot to force a leading zero for the zip code. Either he screwed up the research, or screwed up the coding.
Having had to deal with SSNs and ZIPs when programming, I can say that there are a (very) few tricks that are made possible by treating those data as numbers, but many more problems. The thing that they don't seem to understand is that these "numbers" (I'm including bank accounts, etc) are really labels and not numbers at all. Proper zero-padding can be critical.
Also, most of the useful number-based tricks are made possible with strings if you get the user interface to force properly formatted data and faithfully preserve zero padding in the string as well.
And in some versions of FORTRAN you can use the ENCODE and DECODE statements to effectively read the data twice: once as a literal and again as a numeric field, if for some reason you really want to have it as a number . . . and if for some reason you really want to use FORTRAN . . .
It Beats Doing Your Report Program In Assembly Language Maru
-- Ronn! :)
_______________________________________________ http://www.mccmedia.com/mailman/listinfo/brin-l
