home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11383 < prev    next >
Encoding:
Text File  |  1992-07-22  |  2.0 KB  |  60 lines

  1. Path: sparky!uunet!mcsun!fuug!demos!kiae!glas!demos!bcrka451.b!bcrki65.bnr.ca!sjm
  2. From: sjm@bcrki65.bnr.ca
  3. Newsgroups: comp.lang.c++
  4. Date: 18 Jul 92 00:48 MDT
  5. Subject: Programming guidelines: naming of d
  6. Sender: Notesfile to Usenet Gateway <notes@glas.apc.org>
  7. Message-ID: <1992Jul17.204822.9087@bcrka451.b>
  8. Nf-ID: #N:1992Jul17.204822.9087@bcrka451.b:564648094:001:1626
  9. Nf-From: bcrki65.bnr.ca!sjm    Jul 18 00:48:00 1992
  10. Lines: 48
  11.  
  12.  
  13. I am interested in your thoughts on naming conventions for (private or
  14. protected) member data.  
  15.  
  16. The ARM, p170, says:
  17.  
  18.    Note that a name cannot denote both a function and a data member.
  19.  
  20.    class Y {
  21.       int f();
  22.       int f;     // error
  23.    }
  24.  
  25. This means of course that I can't have both a data member called "name" 
  26. and a get/set function name() and name(aString).
  27.  
  28. A much more minor problem is my annoying habit of selecting keywords for
  29. data member names, e.g. "virtual" or "template".
  30.  
  31. Some people have suggested using the convention of prefixing data members
  32. with an underscore, e.g. _name, _virtual and _template.   This is recommended
  33. by Plum & Saks in "C++ Programming Guidelines", and recommended *against*
  34. in the Ellemtel coding standards.
  35.  
  36. I am somewhat drawn to this convention (I hate fName, fVirtual, fTemplate),
  37. but am also somewhat alarmed by the ARM, p.7:
  38.  
  39.    Identifiers starting with a single underscore (_) should also be
  40.    avoided by ordinary users since C implementations reserve those for
  41.    their own use.
  42.  
  43. My questions are:
  44.  
  45. 1.  What conventions do you like for naming private and protected data
  46.     members?  Why?
  47.  
  48. 2.  What naming conventions do you use for get/set functions?
  49.  
  50. 2.  Why the worry about what C compilers might do?  I have no intention
  51.     of compiling C++ code with a C compiler  --  or are cfront compilers
  52.     equally dangerous?
  53.  
  54. Stuart
  55.  
  56. : Stuart MacMartin                                    email: sjm@bnr.ca      :
  57. : Bell-Northern Research                              phone: (613) 763-5625  :
  58. : PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA    Standard disclaimers apply. :
  59.  
  60.