home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / c / 11632 < prev    next >
Encoding:
Internet Message Format  |  1992-07-26  |  2.7 KB
  1. Path: sparky!uunet!cs.utexas.edu!asuvax!ncar!noao!amethyst!organpipe.uug.arizona.edu!news
  2. From: dave@cs.arizona.edu (Dave Schaumann)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: My view of variable naming conventions (was: Hungarian...)
  5. Message-ID: <1992Jul27.055903.24627@organpipe.uug.arizona.edu>
  6. Date: 27 Jul 92 05:59:03 GMT
  7. References: <1992Jul27.013310.24591@uwm.edu>
  8. Sender: news@organpipe.uug.arizona.edu
  9. Reply-To: dave@cs.arizona.edu (Dave Schaumann)
  10. Organization: University of Arizona
  11. Lines: 44
  12. In-Reply-To: markh@csd4.csd.uwm.edu (Mark William Hopkins)
  13.  
  14. In article <1992Jul27.013310.24591@uwm.edu>, markh@csd4 (Mark William Hopkins) writes:
  15. >(0) Declare as close to 0 variables and parameters at any scoping level as
  16. >    possible.
  17. >(1) Declare all objects as local as possible, even within a statement block.
  18.  
  19. Absolutely.  There's even a name for this: "encapsulation".  To get more
  20. practical: use structs to group related variables, even if makes the actual
  21. code a bit longer.  Ultimately, you'll find it makes maintenence easier when
  22. related variables are related by a physical structure in the code (as opposed
  23. to use and unreliable or nonexistant documentation).
  24.  
  25. >(2) Use generic names for generic objects, and short, common (and appropriate)
  26. >    natural language words for objects with semantic content.
  27.  
  28. Yes.  The length of a variable name should be proportional to the acreage
  29. of code its scope occupies.  1 letter for a 3-line index counter, and something
  30. rather longer for something global to the whole program.
  31.  
  32. >(3) If you have to comment on a variable's use, then you've named it wrong.
  33. >    Rename it.
  34.  
  35. Yah.  A bit of care in naming global identifiers and functions goes a long way.
  36.  
  37. >Experience with my own code and other people's code have borne out this
  38. >assessment time and time again:
  39. >
  40. >    If you find yourself reverting to Hungarian Notation,
  41. >    then you've violated all the above, (0) through (5).
  42.  
  43. Programming in the large is as much about managing complexity as it is about
  44. solving the problem at hand.  Any competant programmer can solve all the 
  45. problems that comprise a large program *in isolation*.  And the key to
  46. managing complexity lies in careful use of encapsulation and abstraction.
  47.  
  48. If you're having problems remembering the type of a variable, you're
  49. probably better off rethinking you're program's abstractions, rather
  50. than adopting some bizarre naming convention that's harder to remember
  51. how to use than it is to remember the types of your variables
  52.  
  53. -- 
  54. You unlock this door with the key of imagination.  Beyond it is another
  55. dimension: a dimension if sound, a dimension of sight, a dimension of mind.
  56. You're moving into a land of both shadow and substance, of things and ideas.
  57. You've just crossed over into... the Twilight Zone.
  58.