home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / c / 11781 < prev    next >
Encoding:
Text File  |  1992-07-30  |  3.3 KB  |  83 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!microsoft!wingnut!russpj
  3. From: russpj@microsoft.com (Russ Paul-Jones)
  4. Subject: Re: My view of variable naming conventions (was: Hungarian...)
  5. Message-ID: <1992Jul30.191531.20810@microsoft.com>
  6. Date: 30 Jul 92 19:15:31 GMT
  7. Organization: Microsoft Corporation
  8. References: <1992Jul27.013310.24591@uwm.edu>
  9. Followup-To: comp.programming
  10. Lines: 71
  11.  
  12. This really isn't a C issue, so I've directed followups to comp.programming.
  13.  
  14. In article <1992Jul27.013310.24591@uwm.edu> markh@csd4.csd.uwm.edu (Mark William Hopkins) writes:
  15. >
  16. >Experience with my own code and other people's code have borne out this
  17. >assessment time and time again:
  18. >
  19. >    If you find yourself reverting to Hungarian Notation,
  20. >    then you've violated all the [below], (0) through (5).
  21. >
  22.  
  23. I'm not sure what you mean.  If you mean that you only need to resort 
  24. to Hungarian when you've already broken the rules, I'll disagree by 
  25. saying that I start with Hungarian in new code.  For those rules that 
  26. I agree with, I find Hungarian a good implementation.  If you are saying 
  27. that Hungarian itself violates these rules, well:
  28.  
  29. >I've always followed these rules in naming objects, like variables in C (or
  30. >Pascal):
  31. >
  32. >(0) Declare as close to 0 variables and parameters at any scoping level as
  33. >    possible.
  34.  
  35. Hungarian neither requires nor encourages extra variables and parameters.  
  36. It does encourage extra typedefs, but you can control this.
  37.  
  38. >(1) Declare all objects as local as possible, even within a statement block.
  39.  
  40. Hungarian is a naming convention, not rules on where to declare the objects.
  41.  
  42. >(2) Use generic names for generic objects, and short, common (and appropriate)
  43. >    natural language words for objects with semantic content.
  44.  
  45. Hungarian establishes short, common names with semantic content for generic 
  46. objects.  They are not natural language words, but I believe it is easier 
  47. to establish short names with semantic content using Hungarian than in 
  48. casting about for appropriate natural language words for objects.
  49.  
  50. >and these rules:
  51. >(3) If you have to comment on a variable's use, then you've named it wrong.
  52. >    Rename it.
  53.  
  54. Using Hungarian, I almost never comment on a variable's use.  The point of 
  55. the name is to define its use.
  56.  
  57. >(4) If you run into numerous name clashes, then you've violated (0) and (1).
  58. >    Eliminate the extraneous fluff.
  59.  
  60. Properly used Hungarian will in fact show up violations of (0) and (1), as 
  61. you are supposed to use identical names for objects being used in 
  62. identical ways.
  63.  
  64. >(5) If you find yourself getting confused about types, then you're not
  65. >    thinking straight about what your program is supposed to be doing.
  66. >    Go back to the drawing board.
  67. >
  68.  
  69. Again, Hungarian is not about types, it is about usage.  Is this rule 
  70. saying that random variable names in code are OK as long as the programmer 
  71. is thinking straight about what the program is supposed to be doing?
  72.  
  73.  
  74. I still have a 40K document describing a dialect of Hungarian close to 
  75. what I use.  This dialect is distinct from that used in the Windows SDK 
  76. documentation.  It is available on e-mail request.  Most of the discussion 
  77. on Hungarian that I've seen has nothing to do with the naming convention 
  78. I use.
  79.  
  80. -Russ Paul-Jones
  81. russpj@microsoft.com
  82. As far as I know, Microsoft does not endorse Hungarian notation.
  83.