Which is the most common in C++? Is it different between member functions and free functions? Obviously the standard lib uses snake_case for everything, but almost nobody uses that.
-
6To quote Bjarne somewhat misleadingly: "Nobody knows what most `C++` programmers do". – BoBTFish Oct 03 '13 at 08:38
-
For your own projects, use whatever you are most comfortable with. If working on existing projects, adapt to the existing style. – Some programmer dude Oct 03 '13 at 08:40
-
This is a conventional issue in context of the project. Many companies and/or mature projects has written conventions what to use. The code itself should show what everyone else has used. If in doubt, however, check with the project leader, the developer forum or maybe some README text. – gustafbstrom Oct 03 '13 at 08:41
-
3I'd like to point out everyone is responding as if the question is "what style should I use", rather than "what style is the most common", which is at least theoretically answerable, if one could analyse every line of `C++` in existence. – BoBTFish Oct 03 '13 at 08:43
-
1*Obviously the standard lib uses snake_case for everything, but almost nobody uses that* I think you'll find in the C and C++ world a majority of people do use snake_case. – Simple Oct 03 '13 at 08:44
-
1"use whatever you are most comfortable with". I'm really tired of that statement. I'm about equally comfortable with everything, and that doesn't matter at all. – user2841816 Oct 03 '13 at 08:45
-
@Simple: Perhaps in the C world (I've contributed quite some C code in my days), but it doesn't seem so in the C++ world. – user2841816 Oct 03 '13 at 08:46
-
@Simple Not where I work! We have at least millions of lines of code in `camelCase`. Also, not *everything*. There is of course that abomination, [`std::ios_base::Init`](http://en.cppreference.com/w/cpp/io/ios_base/Init) (ok, it's not a function, but it's the only counter-example I know of in the Standard Library. Other than template arguments and macros of course.) – BoBTFish Oct 03 '13 at 08:47
-
If you use `PascalCase`, you can't get your classes to work with the __range-based `for`-loop__ without breaking the consistency: http://stackoverflow.com/q/8164567/3425536 – Emil Laine Aug 08 '15 at 13:29
-
@emlai What about `PascalCase` prevents range-based for-loop from working? – Lone Learner May 17 '18 at 05:35
-
@LoneLearner C++ requires the names of the member functions to be exactly `begin` and `end`. – Emil Laine May 17 '18 at 12:58
2 Answers
A lot of people (including me) prefer the underscore_style
. I think from my 20+ years of experience, currently working in a 100.000+ employees company, having reviewed other company's code, etc. I would expect the underscore style to be the most commonly used style. Why? The STL uses it and almost everyone uses the STL. Also, large parts of Boost use it. Of course, there is no way to prove this.
In some domains other style guides or habbits are in place with different naming conventions, but this might be misleading you if you are in such environment to think that it is also common in other places.
To answer your question about member- vs. free functions: I don't think there is a difference wrt the style used.
What I think is most common in C++ is:
- Template parameters: They are usually
PascalCase
. - Macros: They are usually
UPPERCASE_UNDERSCORE_STYLE
. - Most everything else, including function-, method-, variable- and parameter-names are underscore style.
There are also studies about the underscore style, here's an except from a study from 2010:
Although, no difference was found between identifier styles with respect to accuracy, results indicate a significant improvement in time and lower visual effort with the underscore style.
These studies will IMHO lead to even more adoption of the underscore style in the future. But again, there is no way to prove this (or to predict the future).

- 55,810
- 13
- 122
- 180
-
I have no preference, I was just wondering which is the most common. – user2841816 Oct 03 '13 at 08:49
-
@user2841816 I don't think one can really measure which is "most common". It might depend on the domain, company, ... (Downvoter: Why?) – Daniel Frey Oct 03 '13 at 08:51
-
-
@BoBTFish Because the question can not be answered directly. I just tried to add something useful, a link to a study instead of just one more opinion or guess as to what it "most common". (Have you seen the tooltip on the downvote button?) – Daniel Frey Oct 03 '13 at 08:57
-
@DanielFrey "This answer is not useful". Not "this statement is not useful". It's a good piece of advice, that is not an answer to this question. – BoBTFish Oct 03 '13 at 09:00
-
-
-
What is your recommendation on class names? Should class names be `undercore_separated` or `PascalCased`? – Lone Learner May 17 '18 at 05:36
-
1@LoneLearner I prefer class_names_like_this, i.e. underscore-style, because it is what the STL uses: shared_ptr, unordered_set, etc. – Daniel Frey May 17 '18 at 06:41
-
The [linked document](http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf) performs some statistical ninjitsu and looks like `snake_case` does indeed win from a readability standpoint, at least per their analysis, which makes sense given the spacing between words. – Nov 18 '18 at 08:16
-
If so then `foo( param1, param2 )` (my pet indentation style) might be more readable than the standard `foo(param1, param2)` for that same reason. – Nov 18 '18 at 08:18
-
1@hacksalot I prefer that style as well. We even formalized our official style here: https://github.com/taocpp/PEGTL/blob/master/.clang-format – Daniel Frey Nov 18 '18 at 08:25
-
Ha! Nice! I knew I wasn't the only one. That is excellent. To me the padded invocation style allows your parameters to breathe. It says, "function, I am invoking you with confidence and precision, not stuffing you like a turkey on Thanksgiving." There's also an element of *deliberation* which to me makes it easier to mentally parse the code. – Nov 18 '18 at 08:54
It depends. If you're working alone, I'd recommend picking a standard and going with it. If there's some code you're interfacing with, it may make sense to follow that code style.
On projects without a defined style guide, I default to the Google C++ style guide (https://google.github.io/styleguide/cppguide.html).