home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / edu / 1597 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  2.4 KB
  1. Xref: sparky comp.edu:1597 comp.lang.fortran:3495
  2. Newsgroups: comp.edu,comp.lang.fortran
  3. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!spool.mu.edu!agate!dog.ee.lbl.gov!hellgate.utah.edu!lanl!cochiti.lanl.gov!jlg
  4. From: jlg@cochiti.lanl.gov (Jim Giles)
  5. Subject: Re: Case Sensitivity (was Re: Small Language Wanted)
  6. Message-ID: <1992Sep9.195806.1471@newshost.lanl.gov>
  7. Sender: news@newshost.lanl.gov
  8. Organization: Los Alamos National Laboratory
  9. References: <DAVIS.92Aug23010605@pacific.mps.ohio-state.edu> <1992Aug25.034553.2990@linus.mitre.org> <1992Aug25.104211.1@vxdesy.desy.de> <999@engcon.marshall.ltv.com> <9SEP199210424176@seqvax.caltech.edu>
  10. Distribution: usa
  11. Date: Wed, 9 Sep 1992 19:58:06 GMT
  12. Lines: 33
  13.  
  14. In article <9SEP199210424176@seqvax.caltech.edu>, mathog@seqvax.caltech.edu (David Mathog) writes:
  15. |> [...]
  16. |> Sure, but it's a recipe for maintenance problems should one of the 99.999%
  17. |> of C programmers who aren't s&c engineers ever be called upon to modify the
  18. |> code.  That said, Fortran code with variables named I12, I21, I13, I31 (and 
  19. |> so forth) is just about as difficult to maintain.
  20. |> 
  21. |> There must be some studies on the rate at which programmers misread code as
  22. |> a function of variable length and format - anybody out there know the
  23. |> results? 
  24.  
  25. I have a Pascal book (at home, or I would quote it directly) which 
  26. elegantly makes the case *against* long identifiers by arguing *for*
  27. them.  They compare Fortran-like identifiers (say GRDSIZ and BOXSIZ)
  28. to Pascal identifiers (like Size_of_Grid and Size_of_Box) and conclude
  29. that the latter are best.  Well, I disagreed (and their examples made
  30. the point better than mine).  If two identifiers specify different
  31. things, their *differences* should be the emphasis of the names - not
  32. their similarities.  Reading lots of *long* identifiers is just as
  33. prone to error and misunderstanding as having inadequately short ones.
  34.  
  35. I think there's no doubt that restricting identifier lengths arbitrarily
  36. in the language design (to anything shorter than 16 or 20 anyway) is not 
  37. conducive to well written code.  But, arbitrary use of extremely long 
  38. identifiers, just to use up the space, should not be the result.  In the 
  39. above examples, GRID_SZ and BOX_SZ are admirable - yet are not long.
  40. Extremely long identifiers (more than 10-16 characters, say) should
  41. only be necessary when you're trying to emphasize something very
  42. unusual or when you have very subtle distinctions between what two 
  43. (or more) variables do.
  44.  
  45. -- 
  46. J. Giles
  47.