🚀 go-pugleaf

feb6399@osfmail.isc.rit.edu (Frank Barrus) wrote:
>Or shall all old code of this sort be simply converted to use
>access methods, and should directly accessible public 
>instance variables be completely avoided?

As a general rule, directly addressable public data is to be avoided,
for a variety of reasons.

>If that's the case, then I'd like to stick with some sort of 
>standard naming convention...  but I've seen all kinds of different
>variations...

Let me put in my two cents worth:

A verb in a member function name should indicate that the function is
not const, and vice versa.  It is, after all, useful to know which
you're working with at any given time.  Thus for property foo, which
may or may not be an explicit member of class Bar, we have:

class Bar
{
	public:
		int foo() const;
		void setFoo(int);
			or
		void set_foo(int)
	private:
		int myFoo;
};

I like the "my" prefix for non-static member variables, as you can
see.

Note that underscores preceding a name are often reserved by the
system.  While underscore followed by a lowercase letter is not
reserved, it is probably better to avoid using it anyway.

Andrew Bell
abell@mindspring.com
 
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]