views:

344

answers:

7

What naming convention should I follow for class members? Right now, I’m prefixing all fields with an underscore, and using the regular name for the accessor method, e.g.: int _age and int age() { return _age; }

Any preferred approaches?

+1  A: 

Take a look at C++ Coding Standard

adatapost
A: 

Personally I would recommend to start member variables with m_ and the accessor method with get and set prefixes, e.g.: m_age and int getAge() {}.

For a good rule set of naming conventions and best practices read these two books:

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=sr%5F1%5F1/187-8545911-6271721?ie=UTF8&s=books&qid=1252936825&sr=8-1 (general programming style)

http://www.amazon.com/Coding-Standards-Rules-Guidelines-Practices/dp/0321113586/ref=sr%5F1%5F1/177-5450861-2480140?ie=UTF8&s=books&qid=1252936836&sr=8-1 (C++ specific)

Maximilian Schweitzer
A: 

This is really different from person to person. Personally I go for "int _age" with "getAge()" and "setAge(...)". It is quite common to use names with verbs for methods to get a feeling for what it does. Just calling a method "age" may be a bit diffuse. But again, it's all about taste.

Dentoid
A: 

Depends. I prefer using:
_age for the fields
getAge and setAge for accessor methods
It's simply a matter of style... but if you precede your accessor methods with get/set, then your code will be clearer (I'm assuming you're working in C++)

Aviral Dasgupta
+1  A: 

I'd recommend against the leading underscore. The ones you're using are legal, but since some names beginning with underscores are reserved for the implementation I'd rather avoid them entirely.

Where I am, we use m_, such as m_age, to represent members. It works pretty well.

Also, are you under the impression that you should have accessors for all class members? Public functions should expose the class behavior, not the class members.

David Thornley
+3  A: 

You shouldn't use underscore prefix. It is reserved to the implementation according to C++ standard 17.4.3.1.2/1:

Certain sets of names and function signatures are always reserved to the implementation:

  • Each name that contains a double underscore (_ _) or begins with an underscore followed by an upper-case letter (2.11) is reserved to the implementation for any use.
  • Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

You could take a look on Google C++ coding style.

Kirill V. Lyadvinsky
Single underscores are only reserved in the *global namespace*. That said, I prefer m_ for C++ code.
Roger Lipscombe
No, they are reserved to the implementation. And implementation uses them in the global namespace.
Kirill V. Lyadvinsky
And this is how formatting wars start... I agree with about 1/2 of the google code guidelines. The other 1/2 are just wrong IMO. The best piece of advice on that page is "Use common sense and BE CONSISTENT. "
Glen
@Glen, surely this guidelines suitable not for everyone, but it is a good example from real life.
Kirill V. Lyadvinsky
+3  A: 

Two things:

1) Avoid using the leading underscore. The general convention is that compiler vendors use both an underscore and double underscore as a means to introduce keywords. For example, ___declspec in Microsoft Visual C++. That is why you see the trailing underscore (e.g., int foo_;) in some C++ literature.

2) There is no answer to your question. Sorry to be unhelpful. The C++ community is not like other communities in this respect. Sun has established a style standard for Java. Microsoft has documented a style standard in the MSDN for C#. Other communities tend to follow the style of the programming languages author. "How does van Rossum write Python?" or "How does Matz write Ruby?" You don't see this in C++. Although there is a definitive style to Stroustrup's books, nobody follows it. Even the most notable C++ figures all have their own style.

The only advice I can offer is to be consistent. It doesn't matter what style you choose.

(Note: this is coming from a person with OCD. I can understand the pain of not having a definitive answer on this topic. However, the older I get, the more I learn to let go of the matter.)

Nicholas Salerno