I do a lot of work in Python and Java, and both those languages have fairly common (though not universal) conventions on how capitalization should be used in identifiers: both use PascalCase for class names and ALL_CAPS for "global" constants, but for other identifiers a lot of Java code uses mixedCase whereas a lot of Python code uses underscore_delimiters. I know that no language or library enforces any particular capitalization, but I've found that when I stick to the standard conventions for the language I'm using, my code seems much more readable.

Now I'm starting a project in C++, and I'd like to apply the same idea. Is there any most common convention for capitalization that I should know about?

  • The problem with camelCase is that it doesn't play nicely with the preprocessor. Not a huge problem, especially since the preprocessor can usually be avoided.
    – Pubby
    Commented Oct 11, 2011 at 0:46
  • I had to face this decision just a few days ago. In the end, it was a no-brainer, since both the standard library and boost uses underscore_lowercase_delimiters. Since I use boost as an STL booster it will be sprinkled all about my code. Other libraries I use that are PascalCase (SFML) can more easily be contained so any given method is pretty standard.
    – Max
    Commented Oct 11, 2011 at 1:38
  • @Pubby8: out of curiosity: how does camelCase clash with the preprocessor? Commented Oct 11, 2011 at 12:42
  • @JoachimSauer Individual words in camelCase may have a different case, but macros can't change case. This becomes a problem if you want a macro that takes part of a word as an argument - you may have to supply both cases as arguments: macro(x, X). It's a pretty minor problem, but should be known if you intend to use the preprocessor.
    – Pubby
    Commented Oct 12, 2011 at 0:25

7 Answers 7


Is there any most common convention for capitalization that I should know about?

C++ is based on C, which is old enough to have developed a whole bunch of naming conventions by the time C++ was invented. Then C++ added a few, and C hasn't been idle with thinking of new ones either. Add to that the many C-derived languages, which developed their inventor's C naming conventions further, to the point where they back-fertilized on C and C++... In other words: C++ hasn't one, but many of such conventions.

However, if you are looking for the one naming convention, you might as well look at the standard library's naming convention, because this is the single one that all C++ developers will have to know and be used to.

However, whatever you use the most important rule is: Be consistent!

Interestingly, while I started out with a mix of PascalCase and camelCase, and was involved in numerous projects with even more numerous naming conventions, over the years I find I got stuck more and more with the standard_library_convention. Don't ask me why.

  • Thanks for the info... so the standard library is underscores, then? (at least more so than anything else?) I was thinking along those lines, but it was kind of hard to tell because of things like iostream in which half the method names seem to be the same sort of mushed-together word fragments as ANSI C :-P
    – David Z
    Commented Oct 10, 2011 at 23:15
  • 6
    @David: The iostreams library is probably 25 years old, and (except for the C lib, or course) might be the oldest part of the C++ std lib. Hopefully, nobody in their right mind would design it the way it is nowadays, and hopefully even those not in their right mind wouldn't pick identifiers the way they are used in the streams library. (C'mon, there's functions named egptr, sputn, and uflow as well as underflow. That's just hilarious!) Anyway, yes, the std lib nowadays uses all_lowercase_with_underscores.
    – sbi
    Commented Oct 11, 2011 at 9:06
  • @sbi I found out that iostream library is no longer consider a standard library for C++. And as you mention, its identifiers are not useful as a programming convention ;-)
    – umlcat
    Commented Oct 11, 2011 at 17:05
  • 2
    @umlcat: The iostreams library (in its templatized from as accepted for C++03) is most definitely considered part of the C++ standard library.
    – sbi
    Commented Oct 11, 2011 at 17:08
  • I've gone down the same route too.I think the reason I have is camelCase is slightly easier to type & I wanted to be lazy there. Later I learned I spent more time reading and refactoring my code than writing it, and snake_case is easier to read. So it's all about minimizing energy expenditure. Now I'm playing with using lower case names for classes. It's unconventional, however I think switching it around and uppercasing important Instances and lowercasing types actually improves the readability of my code. I'm thinking maybe this is the way to go. Uppercase what's important, like in humanese. Commented Jul 2, 2016 at 13:16

Let's first agree that ALL UPPERCASE is an eyesore and should be minimized.

In C and C++ it's therefore used as a convention for macros, and macros only, because macros are equally ugly, not to say evil.

Early C didn't have const, so constants had to be expressed as macros. Also, in those early days programs were much shorter, so that the practices that are ungood today could be used (e.g. IIRC Brian Kernighan wrote code with lots of non-uppercase macros). And also, in those days keyboards that didn't have lowercase letters did exist; I used one such, on the Norwegian Tandberg EC-10 computer, about 1980 or 1979 I think it was.

So, Java picked up the uppercase convention for constants from early C. Meanwhile, and perhaps even before that (I'm not sure of the chronology here), C got constants. However, while of course some/many C programmers were stuck in the earlier convention-by-necessity of constants as uppercase macros, C++ programmers were more sensible.

The big problem nowadays is when people are taught Java first, or C (with conventions from the middle ages) first, and then come to C++, taking that foul uppercase convention with them.


    int const answer = 42;    // Nice, good, OK.
    const int ANSWER = 0x2A;  // Ouch!
    #define COMPANYNAME_ANSWER 052  // Oh kill me, please.

Well you might have thought I mentioned uppercase-only keyboards in jest. Oh no. Because that's merely the oldest, most archaic technology limitation that has driven naming conventions, or at least affected how wrong/right they have seemed. Next, there was the problem of 7-bit serial transmission, which caused corresponding problems with the character codes (newspeak character encodings) used, which meant you had to restrict yourself to the letters of the English alphabet, A through Z.

Actually I recommend still doing that. That's where we're at! We haven't got further.

At the moment, as of 2011, standard C++ supports general Unicode in names (and has done so since 1998), while actual C++ implementations do not. In particular the g++ compiler is national character challenged. It stems from that dark ages technological limitation.


    double blueberryJamViscosity  = 0.0;    // OK
    double blåbærsyltetøyViskositet = 0.0;  // Ouch!

Finally, on the subject of underscores versus interspersed uppercase letters,

  • Reserve an easily recognized form for type names.
  • Reserve ALL UPPERCASE for macros.
  • Be consistent.

I think that's that, really, except for rules like "generally avoid single-letter name except for (loop, template param, blah blah)", and "avoid using l, easily confused with 1" and "avoid uppercase O, easily confused with 0". Also, of course, avoid using reserved names like starting with underscore followed by uppercase, containing two successive underscores, or starting with underscore and being in the global namespace.

Cheers & hth

  • Alf, ISTR Stroustrup mentioning in D&E C copying const from C++, so this must have happened very long ago, and long before Java, probably for C89.
    – sbi
    Commented Oct 11, 2011 at 8:55
  • 2
    Oh, and a heartfelt +1 for "Be consistent!" Reading it I wonder why I forgot to mention this, the most important, rule in my answer, when it was the one I never forgot to tell my students. I suppose you will forgive me if I now add it to my answer as an afterthought?
    – sbi
    Commented Oct 11, 2011 at 8:57

I usually tend to stick with the convention that I see most in existing codebases for the language. In the case of C++, I usually see camelCase. In the case of Ruby or PHP I usually see stuff_like_this.

Realistically speaking, though, the most important thing is that you pick a style convention that isn't totally insane (dOnT_dO_tHiS) and be consistent with it. Make it so the style doesn't change throughout the code for a particular project. If you are working on an existing project, you'll want to go with the style that is already there.


Well, there's Systems Hungarian which is really common even now, but I'd rather cut my own throat than recommend it. Apps Hungarian is better as its annotative marks are truly indicative of semantics, though I feel that it's a little too keen on abbreviations when a short word would do. (To use the example from that Wikipedia page, why use rw for row when row is only one character longer? It's not like there's a global vowel shortage.)

Realistically though, the most important thing is to follow the conventions of the people you are working with. Really. Most conventions work well enough, especially if used consistently. Inconsistency is worst (even more so than Systems Hungarian, which I hate). And if you're on your own, use whatever you want.


From what I've seen, it varies between projects.

Embedded underscores are probably more traditional/more commonly used in C on Unix. The standard library follows this as well, so it should almost certainly be treated as the default, to be used unless there's enough existing code using another convention to absolutely force using that other convention.

Windows (for one example) uses camel case for most of its functions, so quite a few people who develop for Windows do the same. This is also fairly common among people who are really more accustomed to other languages, and attempt to treat C++ as if it were just an odd variant of something else.


I have used both standard library and boost as references for naming conventions. However, there is a problem with this solution.

The standard library uses a naming convention designed to attempt to reduce collisions with your code. Part of the solution is to use all lower case letters. Hence the use of underscores instead of camelCase.

I find that camelCase is readable. PascalCase is often used for class names as it represents the equivalent of a proper noun. However, I will break that rule for functors which are more representative of a verb.

I try not to use macros. However when I do, macros are made to look like functions when they can. I also use const values or enums instead of manifest constants, further avoiding all upper case. I typically prefix these symbols with a 'k' to indicate that they are constant.

// instead of a manifest constant
#define HOURS 24

// use const
const int kHours = 24; 

// or enum
enum {
    kHours   = 24,
    kMinutes = 60

This reference describes a naming convention that's pretty similar to ones I've seen used with success in at least three companies I've worked for in the past.

Contrary to an earlier answer, I would avoid following the C++ Standard Library's naming convention in my own code, if for no other reason than to avoid name collisions with the Standard Library.

This previous SO answer on a related topic may also be of interest: https://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier

  • 1
    Umm, you can use the same naming convention without using the same names... and if you really want the same names, you're still protected by namespaces, e.g. std::string vs. gnawme::string.
    – einpoklum
    Commented Dec 11, 2015 at 21:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.