question on boost-compliant code conventions
Hi, This is probably a lame question, but I have some open issues I don't know how are handled in contemporary C++ style, for example with using boost coding convetions. I've been using the CamelCase naming convention from Java recently, where the issues below are non-issues actually. for example: - how do I create an instance of the same name as its type? in CamelCase: class Foo; Foo foo; in C++: class foo; foo foo; // won't compile what's the solution here? add some prefix to the instance's name? - how do I declare accessor functions to private members? in Java / CamelCase: class Foo { private int bar; public int getBar() { return bar; } }; in C++: class foo { private: int bar; public: int bar() const { return bar; } // won't compile }; should I put some prefix to the private member's name? Sorry for the lame questions :) But I just want to follow the guideline of 'in Rome, do as the Romans do' :) Akos
On Mon, Jul 21, 2008 at 10:57 PM, Ákos Maróy
- how do I create an instance of the same name as its type?
I would either A) try and find a better name for the type, or B) find a better name for the instance. If the instance has a very brief lifetime, limited scope, or is otherwise obvious to a developer (e.g. the single parameter to a string utility function), I might abbreviate it's name, usually right down to a single character. string s = "Richard";
- how do I declare accessor functions to private members? ... should I put some prefix to the private member's name?
Not a prefix, but a a trailing underscore suffix is generally used (identifiers starting with an underscore are reserved for the compiler). class foo { public: int bar() const { return bar_; } private: int bar_; }; Cheers, Rich
I see no problems with a mixed style. For what it's worth, I use the following style: Typenames in CamelCase. Function names with underscore_notation. Variable names with camelCase, with the first variable lower-case. Private members prefixed (or postfixed, if you wish) with an _underscore. This manages to avoid most conflicts. And to me, it's very readable. -- Michiel Helvensteijn
participants (3)
-
Michiel Helvensteijn
-
Richard Dingwall
-
Ákos Maróy