getters and setters style

Question

(Leaving aside the question of should you have them at all.)

I have always preferred to just use function overloading to give you the same name for both getter and setters.

int rate() { return _rate; }      
void rate(int value) { _rate = value; }

// instead of     
int getRate() { return _rate; }      
void setRate(int value) { _rate = value; }

// mainly because it allows me to write the much cleaner     
total( period() * rate() );    
// instead of      
setTotal( getPeriod() * getRate() );

Naturally I am correct, but i wondered if the library writers had any good reason ?

Answer 1

A few years ago, I would have agreed completely. More recently, a doubt began to make its way, because that makes taking the address of a getter or setter ambiguous. With tools like tr1::bind, this is really annoying.

For example:

struct A
{
   void Foo(int);
   int Foo()const;
};

std::vector<A> v = ....;
std::vector<int> foos;
// Extract Foo
std::transform(
   v.begin(), v.end(), 
   std::back_inserter(foos), 
   //Ambiguous
   // std::tr1::bind(&A::Foo)
   //must write this instead. Yuck!
   std::tr1::bind(static_cast<int(Foo::*)()>(&A::Foo));
);

Leaving aside the question of should you have them at all ;-)

Answer 2

I enforce the convention in which a method should always be a verb and a class should always be a noun (except for functors, for obvious reasons). In which case, a get/set prefix must be used for consistency. That said, I also agree entirely with Ed Swangren. This sums to me as using those prefixes a no-brainer.

Answer 3

I prefer to avoid the get and set labels, the information is not needed for the compiler to do it's job for most of these simple properties.

you can have issues:

class Stuff {
  void widget( int something ); // 'special' setter
  const Widget& widget( int somethingelse ) const; // getter
}
Stuff a; 
a.widget(1); // compiler won't know which widget you mean, not enough info

Answer 4

Being concise is important, but not at the cost of being incomplete or misleading. For that reason, I prefer GetFoo() and SetFoo() to Foo() and Foo(int foo).

Answer 5

While Ed's comment is true, I do prefer actual properties over the setter/getter antipattern. When 1/3rd of the methods in your domain graph are dummy methods that have been generated by eclipse, there's something wrong.

Without first class properties, however, I believe the antipattern makes the most sense.

Furthermore, it makes code completion easier.

obj.set (control shift space) for setters
obj.get (control shift space) for getters

Answer 6

I'll go ahead and mention this should be a community wiki question.

When I started learning C++ I looked for style guides, and Google's was good for some points:

• Methods in uppercase (it's just prettier).
• getters plainly and lowecase (rate).
• setters explicitly and lowercase (setRate).