home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!fuug!demos!kiae!glas!demos!bcrka451.b!bcrki65.bnr.ca!sjm
- From: sjm@bcrki65.bnr.ca
- Newsgroups: comp.lang.c++
- Date: 18 Jul 92 00:48 MDT
- Subject: Programming guidelines: naming of d
- Sender: Notesfile to Usenet Gateway <notes@glas.apc.org>
- Message-ID: <1992Jul17.204822.9087@bcrka451.b>
- Nf-ID: #N:1992Jul17.204822.9087@bcrka451.b:564648094:001:1626
- Nf-From: bcrki65.bnr.ca!sjm Jul 18 00:48:00 1992
- Lines: 48
-
-
- I am interested in your thoughts on naming conventions for (private or
- protected) member data.
-
- The ARM, p170, says:
-
- Note that a name cannot denote both a function and a data member.
-
- class Y {
- int f();
- int f; // error
- }
-
- This means of course that I can't have both a data member called "name"
- and a get/set function name() and name(aString).
-
- A much more minor problem is my annoying habit of selecting keywords for
- data member names, e.g. "virtual" or "template".
-
- Some people have suggested using the convention of prefixing data members
- with an underscore, e.g. _name, _virtual and _template. This is recommended
- by Plum & Saks in "C++ Programming Guidelines", and recommended *against*
- in the Ellemtel coding standards.
-
- I am somewhat drawn to this convention (I hate fName, fVirtual, fTemplate),
- but am also somewhat alarmed by the ARM, p.7:
-
- Identifiers starting with a single underscore (_) should also be
- avoided by ordinary users since C implementations reserve those for
- their own use.
-
- My questions are:
-
- 1. What conventions do you like for naming private and protected data
- members? Why?
-
- 2. What naming conventions do you use for get/set functions?
-
- 2. Why the worry about what C compilers might do? I have no intention
- of compiling C++ code with a C compiler -- or are cfront compilers
- equally dangerous?
-
- Stuart
-
- : Stuart MacMartin email: sjm@bnr.ca :
- : Bell-Northern Research phone: (613) 763-5625 :
- : PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA Standard disclaimers apply. :
-
-