Good naming convention for private member functions in C++?

Question

For members, I use

//.......vv
SomeType m_XXX;
//.......^^

I'd love to use _ as a prefix for member functions, but names starting with _ or __ are reserved and should not be used.

My idea is, that when I have:

SomeClass myObject;
myObject.[XXX]

when the user (of the lib) write the dot (.), to see all functions (one after another) that are only public.

Is there a common naming convention for this?

_{I know, that I can use pImpl or inheritance, with interface and implementation classes}

You could prefix or suffix the functions with `impl_` or `Impl` if you like... — Kerrek SB, Aug 20 '12 at 10:26
I don't think there is any convention for this. Tapping a dot in most IDEs will differentiate between public and private methods and will show them separately. — Lyubomir Vasilev, Aug 20 '12 at 10:26
I use `_ `for members. but never do `__` its reserved for internals — Neel Basu, Aug 20 '12 at 10:27
@juanchopanza - using suffix will NOT work, as when `.` is written, the order of suggested members is (most likely) alphabetical. — Kiril Kirov, Aug 20 '12 at 10:28
@Nick - using `___` does have prefix `_` and even `__`, doesn't it? — Kiril Kirov, Aug 20 '12 at 10:28
@LyubomirVasilev - really? I've used only SlickEdit (for Linux) and Visual Studio. Slickedit does not do this for sure (at least by default). I'm pretty sure, VS was the same, but I can't test it right now. That's interesting. — Kiril Kirov, Aug 20 '12 at 10:31
@Kiril Kirov From what I remember, Visual Studio used to differentiate them in some way (don't remember what). Now using KDevelop under Linux, it places a different icon in front of public and private methods, and no icon in front of member variables. — Lyubomir Vasilev, Aug 20 '12 at 10:34
I think this is bad practice. If you want to expose a previously private method you now have to update all references to that method. Seems like unneccessary burden. Your IDE should not be putting limiting constraints on code style. — jterm, Apr 25 '19 at 16:55

score 23 · Accepted Answer · answered Aug 20 '12 at 10:27

23

The most common practice is to name member functions without any common prefix or suffix. Personally, I see no benefit in differentiating them, and if your motivation relates to "write the dot (.), to see all functions" then it sounds like you should configure or change your editor, rather than change your programming style to suit it.

answered Aug 20 '12 at 10:27

Tony Delroy

102,968
15
177
252

Ha, that's interesting. I haven't thought about this (that could be controlled by the IDE). Sounds logical. – Kiril Kirov Aug 20 '12 at 10:32
Imagine a class with a member called, say, `id`. And a member function that accepts another id, e.g. `setId(Id id)`. How does an editor help you differentiate these? – Maxim Egorushkin Aug 20 '12 at 10:36
And to call it _most common practise_ you'd need to prove it with statistics. E.g. scanned sources of 5000 open source projects and found that bla-bla-bla... – Maxim Egorushkin Aug 20 '12 at 10:39
1

@Maxim: re `id` - it doesn't... but then why should it? One class is a small enough scope that manually resolving any rare identifier clashes is a breeze... it's not the global namespace. And, believe it or not, I can make statements about common practice on the basis of decades of professional experience. – Tony Delroy Aug 20 '12 at 10:55
_believe it or not, I can make statements about common practice on the basis of decades of professional experience_ - that is called a statistical study with a sample size of one, also known as anecdote. – Maxim Egorushkin Aug 21 '12 at 08:10
2

@Maxim: not so Maxim... I've actually worked on more than one system... the sample size is scores of independent projects at around a dozen companies, plus all the online material, books etc. I've seen. Enough for me to recognise a few sweeping trends. Like, for example, one might have assume this discussion's will remain a complete waste of time, having seen too many like it. If you thought your quip was clever or insightful, think again! – Tony Delroy Aug 21 '12 at 08:20
@TonyDelroy fair enough, I take that back, peace. – Maxim Egorushkin Aug 21 '12 at 08:23

score 11 · Answer 2 · answered Aug 20 '12 at 10:33

11

A good convention is the trailing underscore, like_this_. Leading underscore is the Python way, however, in C++ all identifiers starting with underscore are reserved for the implementation.

Another option is to always prefix member access with this.

answered Aug 20 '12 at 10:33

Maxim Egorushkin

131,725
17
180
271

20

Names that begin with an underscore followed by a capital letter are reserved to the implementation. Names that begin with an underscore followed by a lowercase letter are reserved to the implementation **for use in global scope**. In a non-global scope, a leading underscore followed by a lowercase letter is okay. Which is not an endorsement... – Pete Becker Aug 20 '12 at 22:30

score 1 · Answer 3 · answered Aug 20 '12 at 10:29

1

I prefer using _member and I prefer member variables in _camelCase and for static members No _ and begins with Cap

but never use __or ___ or more than two underscores, it is reserved for Intervals. m_ is very popular and old and I've seen that first in Visual C++. But I personally find that ugly.

I find no reason to differentiate a private and public instance variable. But If its a Class Variable then I start with a BigCap like MyClass::MyVar

and for local variables I use x or x_y . So locals dont conflict with members

answered Aug 20 '12 at 10:29

Neel Basu

12,638
12
82
146

Just wondering Neel... have you had to rename functions as they move private to/from public? Trying to retrospectively think how often I really do it - tricky! What do you do for protected? – Tony Delroy Aug 20 '12 at 10:34
2

Nope. I don't like to name private and public differently. I treat protected and private in the same way. and If you need to move a function from private to public its not a good design at all – Neel Basu Aug 20 '12 at 12:42
1

This isn't about member variables, this is about private vs public methods. In this case I think it is little to no value add but creates a burden if you want to expose a private method publicly. – jterm Apr 25 '19 at 16:58

Good naming convention for private member functions in C++?

3 Answers3