Take the 2-minute tour ×

I've been taught since high school that defining variables like this:

int _a;


int __a;

should be consider bad practice because this would eventually puzzle compilers that use variables starting with an underscore to name temporary variables.

As far as I know this is the reason why some people like to move the underscore at the end of the name, like:

int a_;

However, I see a lot of code all around that makes use of underscore-starting variables. And that code builds fairly well with both Visual Studio 2010 and g++ 4.x.

So I wonder: is this a non-issue nowadays? Are modern compilers smarter about naming conventions?

share|improve this question
Not a real answer, but it's likely that Microsoft's C++ compilers are specifically more lenient about this because it's Microsoft's internal style to use underscores before private member variables (at least in C#). I know that g++ can still have issues with leading underscores. –  KChaloux Mar 25 '13 at 12:26
You might find the answers to this question useful. –  Blrfl Mar 25 '13 at 12:58
@KChaloux if you think Microsoft's C++ compiler team, in existence for well over 20 years, established the rules about acceptable identifier names based on the habits of some folks on the C# team, you don't know how Microsoft works :-). Seriously, it's been 21 years since they released their first C++ compiler and these rules go back that far, or further into the original C compiler codebase. –  Kate Gregory Mar 25 '13 at 21:50
@Kate I was just pointing out that I knew for a fact that they used it in C#. I don't use Microsoft's C++ compiler, or know terribly much about the environment there, so I was inferring their use of that naming style in C++ from my experience with C#. Never made any claims that the C# rule came first. –  KChaloux Mar 26 '13 at 12:25
add comment

3 Answers

up vote 10 down vote accepted

You are apparently misunderstanding the reason prefix underscores are bad practice. To make it short, it is because the C and C++ standard reserve these prefix for implementation details, for example for standard library implementation. (note that _ and __ are not reserved for the same things, see comments)

Even if the names are under scope (namespace, class, etc.), there can be some global names, in particular macros, which use these prefix and might silently break your code if you use them too.

So, basically, most of the time it is safe to use these prefix BUT if you don't use them you have a 100% guarantee that your naming will never conflict with the implementation names.

Which is why, in doubt, don't use these prefix.

share|improve this answer
your comments apply to the prefix of two underscores but not to a single underscore –  Kate Gregory Mar 25 '13 at 13:00
@KateGregory: Names with a leading underscore are reserved for use by the implementation for names in the global namespace. A leading underscore followed by a second underscore or capital are reserved for any use (they can be used for macros by the implementation). So, a leading underscore followed by a lower-case letter might be ok in local scopes but is best avoided to avoid tripping up and using a reserved name. –  Bart van Ingen Schenau Mar 25 '13 at 13:37
@KateGregory: As a member, _limit is not an error, but as a global function it is. I think it is better to have a simple policy that says "don't use leading underscores, without exception" than a policy that allows them in some contexts and not in others. But we can agree to differ on that. And just to be clear, I have no problems with underscores at other places than the very beginning. –  Bart van Ingen Schenau Mar 25 '13 at 14:17
@BartvanIngenSchenau: just for interest: a simple policy like "use leading underscores just and only for private class members" should not lead to technical problems, what do you think, is that true? –  Doc Brown Mar 25 '13 at 16:35
@KateGregory Just to clarify, I agree that the rules are more precise that what I'm saying in my answer; but it reflect the lack of precision of my memory when I try to remember what are exactly the rules. As I tend to avoid having to know exceptions (not the feature), I prefer general rules easy to follow, in particular for such not-that-important rules. The fun thing is that I'm more at ease with move semantic than remembering this. Maybe that's not fun now that I think about it... –  Klaim Mar 25 '13 at 21:46
show 2 more comments

Using two underscores is definitely bad - that is reserved for compiler-specific implementation details. This does not apply to using one underscore.

Some people have a hate on for underscores. Whether you call something m_index or highest_price or _a - they detest it. I worked with someone 25 years ago who told me about a specific IBM printer (a very popular one) that fit more lines on the page by omitting the bottom pixel on every other line. This was fine for memos, or for output of big swathes of numbers and such, but had the effect for code of making half of your underscores invisible. (Yes, really!) People from that generation generally have the irrational underscore hate, either from interaction with that printer or from working with someone who beat into them that underscores are not to be used.

Most people find using mixed case (an option we didn't have in, say, Fortran) a more readable approach: mIndex, HighestPrice, a stand up pretty well to the earlier underscored examples. I will give you two rules:

  • never start anything (function, variable, macro, typedef) with two underscores
  • pick a consistent convention ( eg _limit for function parameters, m_limit for member variables, never use underscores, camel case, capitalize every word, Hungarian, something) and stick to it. Don't bop around sometimes with underscores at the beginning, sometimes the end, sometimes not using them, and five different casing conventions. Be consistent.

The printer in question is long gone. If you like to use one underscore at time, feel free to. But understand, underscore haters still exist.

share|improve this answer
add comment

People generally use an underscore to start a variable name in order to indicate that a variable is private.

This is definitely the case in a lot of C# coding standards, which you'll see if you're looking at code in Visual Studio, as you mentioned.

Personally, I like it. It makes it very easy to quickly determine the scope of something without cluttering up the variable name.

share|improve this answer
however in C++ (which this question is tagged) there are rules about the meaning of underscores at the beginning of a variable name that do not apply in C#. Not all C# coding standards and practices can safely be used in C++ –  Kate Gregory Mar 25 '13 at 13:59
Good point. I completely missed the fact that this question was targeted to C++. My bad. –  CLandry Mar 25 '13 at 15:08
add comment

Your Answer


