m_Why?

[Pickle Gunner]

Why does it seem everyone uses the prefix 'm_'? Could someone explain?!?!

[Zaita]

m_ stands for member. It's used to identify members of a class. It really depends on the coding style you're using.

[Pickle Gunner]

Is there any other ?_ Things I should know?

[Zaita]

It's all based on the coding standard you use.

For example, Google uses: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
Oracle has their own etc. most large companies do.

[TheIdeasMan]

Using m_ for member variables can be convenient in naming parameters to functions:

CRect::CRect(const double& Width, const double& Height) : m_Width(Width), m_Height(Height){}

As you can see I use C for class, and I also use p for pointer variables. I don't go any further than that for pre-pending variable names. I do sometimes put the container type on the end as in GroupLst, PeopleVtr, PointMap, PointSet. IMO, pre-pending & appending types is OK as long as one doesn't get carried away with it - what I have mentioned here is the limit of what I do, and it is a personal preference.

I also like CamelCase for variable & function names, Upper case for constant variables, and no underscores in anything except member variables because they make the name too long.

There was some debate about whether leading underscores in variable name would cause problems because that meant they were reserved for something, but I have never done that.

Edit: Just read some of the Google style in Zaita's link - interesting & good :)

[rapidcoder]

This is a leftover from ancient times when programmers didn't have powerful IDEs which would mark members with a different color.

[ne555]

CRect::CRect(const double& Width, const double& Height) : 
   Width(Width), //no problem here
   Height(Height)
{
}

[MiiNiPaa]

I prefer '_' as a postfix for arguments: CRect::CRect(const double& Width_, const double& Height_)

[LB]

I personally don't like the style, it seems redundant and it also has no place in PIMPL.

There is another style used in C where you would prefix all struct members with an abbreviation of the name of the struct - this is mainly so that macros can be defined to change which member you actually access (e.g. automatically use a different member when compiling for unicode) but again it has no place in C++.

You should have very very few naming conflicts if you always use UpperCamelCase for classes and their members and lowercase for parameters and local variables. At least, I have never had a naming conflict and have never had to resort to ugly underscores which are a pain to type.

[chrisname]

I'm considering it for private members so that I can do this:

public:
    const std::string& str();
    void str(const std::string&);
private:
    std::string m_str;

I wouldn't do it for public members because it would make the interface ugly, and say what you want about practicality, but programmers are people too and like things to be visually appealing. I know I'm more likely to use a library if my code looks pretty when I do. Otherwise I usually hide it behind an abstraction layer (although that's usually not a bad idea anyway, since it makes it easier to port to a different library).

As for naming conventions in general, mine vary with what I'm writing, although it never varies within a single program/library. I like to be consistent with the standard library of the language I'm using, so while in C# I use UpperCaseWithNoUnderscores for everything, I use UpperCaseForClasses.lowerCamelCaseForMembers in Java, whereas in assembly, C and C++ I use lower_case_with_underscores for everything. I generally try to name things in the most descriptive, plain-sounding way and I usually avoid abbreviations and acronyms except in local and private variables.

[TheIdeasMan]

@chrisname

I like to be consistent with the standard library of the language I'm using, ....... whereas in assembly, C and C++ I use lower_case_with_underscores for everything.

I would prefer to differentiate my naming convention from the standard library. In my mind that makes it easier for others because they are less likely to think my (or your) code is part of the library. I guess it's easy to check whether something belongs to a library or not, but if one uses a different convention, then there is no need.

I would also prefer to use the same convention for kind of similar languages. Not that I have done C# or Java, but I think my preference is still OK.

As Zaita said, it boils down to the coding standard you might have to use.

Gee, I hope the OP is learning a lot ! We have derailed the thread a bit.

[LB]

If you're extending part of the standard library (e.g. a new stream or streambuf class) then you should follow the naming conventions of the standard library. Otherwise, keep your naming conventions different from the standard library to emphasize the difference.

[chrisname]

@TheIdeasMan, LB
My code will never be in the std namespace (in fact I always put code of any significance in its own namespace), and the programmer should be prefixing identifiers that are in that namespace with std::, so there shouldn't be any confusion.

[LB]

::std::string mystring {"Hello, World!"};
::std::endl(::std::cout.::std::ostream::operator<<(mystring.::std::string::c_str()));

http://ideone.com/oLRoPB
I agree, there would be no ambiguity when using existing instances of objects from either the standard library or your library.

[/sarcasm]

Obviously when accessing types and static/global objects and functions there would be no problem, but it may be confusing to look at code dealing with existing instances that *appear* to be an instance of a standard library class...or wait, one of your classes? It could be hard to tell.

Though I do note that for custom types to be supported by the standard library via templates and such you have to follow a naming convention.

Just ignore me, I enjoy finding scenarios where statements are false.

[ne555]

> If you're extending part of the standard library (e.g. a new stream
> or streambuf class) then you should follow the naming conventions of the
> standard library. Otherwise, keep your naming conventions different from
> the standard library to emphasize the difference.
By extension, if you are not extending TIM's library, then your name convention should be different too.

[LB]

I thought that argument might come up.

It is impractical to worry about an uncontrollable situation such as that, however it is perfectly within practicality to deal with guaranteed situations such as the standard library.

[chrisname]

Obviously when accessing types and static/global objects and functions there would be no problem, but it may be confusing to look at code dealing with existing instances that *appear* to be an instance of a standard library class...or wait, one of your classes? It could be hard to tell.

I find that unlikely to happen so long as I'm careful with naming (I am) and I keep the number of variables in each context sensible (I do).

[LB]

I meant that it may be ambiguous to a reader, not to the compiler. Again, just ignore me - I'm just practicing my ability to find scenarios that make statements false.

[chrisname]

I was talking about the reader, not the compiler. The compiler always uses the most scope-local version of a variable so there can only be ambiguity when you use entities with the same name in a single scope, and as we've discussed, I don't do that. Which also happens to make life easy for readers.

Which statement are you trying to falsify, anyway? I stated four things:

1. My code will never be in the std namespace
2. I always put code of any significance in its own namespace
3. The programmer should be prefixing identifiers that are in [the std] namespace with std:: (not ::std:: which is much less visually-appealing even if it is strictly more "correct")
4. There shouldn't be any confusion

You only challenged the fourth. I hold these truths to be self-evident*, and unless you want to challenge the soundness of my argument, the truth of the fourth statement is proven.

* the first, second and third, that is (#1 may be subject to change, albeit unlikely, so if I were to revise it, I would remove the word "never")

[MiiNiPaa]

[...]code of any significance in its own namespace
prefixing [...] with std:: (not ::std:: [...])
There shouldn't be any confusion

//header.h
namespace myCoolNamespace //My library
{
    namespace std //for generic stuff
    {
        std::ostream cout;
         /*...*/
    }
    namespace v10 //implementation differing stuff
    {
        /*...*/
    }
}

//main.cpp
#include <iostream>
#include "header.h"
using namespace myCoolNamespace;//I'm too lazy to type it everytime

int main()
{
    std::cout /*I always use std in standard identifiers*/ << "Hi";//Confusion? What consfusion?
}