naming conventions: prefixes, postfixes

[htirwin]

A lot of people prefix member variables with m. Some use all sorts of prefixes to give clues about the types of different variables. Some use postfix_ for member variables, and some use postfix_ for parameters. Some people don't do any of this.

What do you do? Why is it the best choice?

[3qX21hU5]

Generally I will prefix member variables with a m and that is it. Otherwise it just gets to confusing in my opinion to have a certain way of naming things for every single thing. If you are having to many of the same names that you start having to prefix/postfix everything with something you aren't giving good enough names in my opinion.

But no matter my opinion on the matter the only thing that really matters is you are consistent with whatever naming style you choose.

[LB]

Are you sure you don't mean _postifx instead of postfix_ ?

I don't prefix or postfix any identifiers, I think it's kind of silly except in rare cases. I'm looking at you, MS Hungarian.

[Lachlan Easton]

I prefix private member variables with m_
Basically so that if I encounter foo.m_bar or foo->m_bar it raises a red flag. It also helps to make using the variables in member functions unambiguous. Other than that I don't use any other form of prefix/postfix.

[LB]

Lachlan Easton wrote:

if I encounter foo.m_bar or foo->m_bar it raises a red flag.

So your copy ctors always raise red flags?

[Duthomhas]

Every so often this kind of thread just needs a good kick.
http://www.joelonsoftware.com/articles/Wrong.html

[LB]

I do use some aspects of that, such as ResultFromGiven instead of GivenToResult.

[ne555]

> So your copy ctors always raise red flags?
Yes, having to code a copy constructor is a red flag

[Disch]

ne555 wrote:

Yes, having to code a copy constructor is a red flag

You read my mind. I was just going to reply something similar.

[Duthomhas]

Help, I'm a copy!

[Duthomhas]

Help, I'm a copy!

[LB]

ne555 wrote:

Yes, having to code a copy constructor is a red flag

So having a move-only object such as std::unique_ptr<> as a member is also a red flag?

[N36fSL3A]

No. It's unnecessary.

[Catfish4]

High level language... code to ensure correct cleanup... code to ensure correct copying... and most recently, code to ensure correct moving. Coming soon: a way to un-genericize templates! But I digress.

Some people don't do any of this.

This is what I currently do. I give short names to trivial variables, and reserve self-documenting names for fields and important variables, without adding useless decorations like trailing underscores or prefixes like "m_".

[N36fSL3A]

^Exactly. There's no point in putting those useless things on your code.

Honestly I think it just makes it harder to understand. (*cough* win32 API *cough*)

[3qX21hU5]

Wait are you say unique_ptr is useless or name conventions like putting m infront of member variables are useless?

[N36fSL3A]

Well not useless, just irrelevant to my needs.

I'm usually developing in VC++ so I can just hover over the class and see if its private or not.

I understand if you're using MinGW and Notepad.

Underscores are okay IMO.

[LB]

It's pretty useful for people for whom their brains are not wired for programming and they need excess reminders to help them not mess up.

[N36fSL3A]

I understand that, but I think on large scale projects it just makes everything complicated. To this day I still don't truly understand winAPI simply because MS decided to use Hungarian notation like idiots.

[htirwin]

I've never marked up my variables before. In the book I'm reading now, the author puts a trailing underscore on parameters which are used for initializing variables in the constructor.

class A;

class B {
    A a;
public:
    B(A a_) : a(a_) 
    {}
};

In my most recent project I started doing this. Then in one method, I had the thought that it might help readability to use this explicitly, but then I would have to do it everywhere and that's just ugly and a waste of tim, so I thought maybe I would use the m prefix, but I wanted to see what others think beforehand. I think I wont.