🔒 Locked

gods of the awesome programming! heed my call!

Started by Bru Mar 28, 2010 at 4:10 AM 43 replies 6.1k views

Original Post

Mar 28, 2010 at 4:10 AM

Ho great pro gods of pro awesome programming! i have a question! Every time i browse someone's else code,it seems like they write variablers like m_pVariable. I wonder,what does the m_ stands for? I guess the p is pointer,but what is m? I ask this because i need to set myself some programming rules about giving names to classes and variables,and since all the pros do that i should probably do that too(just that i rather know what it means if i am going to do it). ho! thanks in advance,your slave forever and more everz,Bru.

demonkoryu

Mar 28, 2010 at 4:14 AM

Ok, first calm down. :P

m_ stands for member variable (as in, class member).

And not all the "pros" prefix their variable names.

Personally, after having tried using variable prefixes for a short time, I just use the "this" pointer explicitly.

Bru

Mar 28, 2010 at 4:20 AM

aright,thanks :)

DevFred

Mar 28, 2010 at 6:24 AM

Quote:
Original post by Bru
i need to set myself some programming rules about giving names to classes and variables

The great thing about programming on your own is that you don't really need a strict coding standard ;) Personally, I have never found member prefixes to be that useful. Good IDEs will highlight them differently anyway.

cache_hit

Mar 28, 2010 at 10:09 AM

For reference, it's called Hungarian Notation. Check it out on Wikipedia.

I used to use Hungarian Notation extensively, but I've since elimited it almost entirely from my code. I don't use prefixes at all anymore. The only thing I do now is use _ at the end of a class member. So "foo_" is a class member variable named foo, while "foo" is a local variable named foo.

ozak

Mar 28, 2010 at 10:28 AM

That's funny. I use _ at the beginning. Like _engine ;)

jwezorek

Mar 28, 2010 at 12:14 PM

Generally, don't use Hungarian notation.

Hungarian got popular with Windows programmers because the Win32 API was/is written using Hungarian. If you wanted the Win32 calls to not look out of place in your own code, you had to use Hungarian as well.

Imho, it was a fad and kind of a pointless fad. Carrying around information about the type of a variable isn't really the job of a variable's name and shouldn't be. Compilers do type checking and modern IDE's will tell you a variable's type when you hover the cursor over it.

I do, however, prefix member variables with an underscore. Doing so solves the problem of naming formal parameters of constructors that one would naturally want to give the exact same name as a member variable:

class Foo {   Bar _bar;   Foo(Bar bar) : _bar(bar) { // Don't have come up with another name for "bar"      ...   }}

DevFred

Mar 28, 2010 at 12:18 PM

Quote:
Original post by ozak
_engine ;)

Note that this is forbidden by the standard for global variables. _Engine is also illegal.

See [global.names] for details.

Quote:
Original post by jwezorek
Don't have come up with another name for "bar"

You can reuse the name without problems.

class Foo {   Bar bar;   Foo(Bar bar) : bar(bar) {      ...   }}

jwezorek

Mar 28, 2010 at 12:22 PM

Quote:
You can reuse the name without problems.
class Foo {   Bar bar;   Foo(Bar bar) : bar(bar) {      ...   }}

But it looks weird, imo.

rip-off

Mar 28, 2010 at 12:25 PM

It is idiomatic.

Kasya

Mar 28, 2010 at 12:35 PM

just add any prefix you like or find a synonym or related word (not always) for the parameter

for example i use:

translation -> position
orientation -> rotation
x,y,z -> nx, ny, nz
name -> str (for strings)
param -> param_, param0

etc...

ozak

Mar 28, 2010 at 12:36 PM

Quote:
Original post by DevFred
Quote:
Original post by ozak
_engine ;)

Note that this is forbidden by the standard for global variables. _Engine is also illegal.

See [global.names] for details.

What standard?
It worked for me in C/C++ and C# + Java, and I've been a pro game programmer for over 14 years now :)

demonkoryu

Mar 28, 2010 at 12:50 PM

C++ standard. It reserves these identifier names for compiler implementation stuff. Not that any compiler would care (since it's being used in runtime libraries anyway).

rip-off

Mar 28, 2010 at 12:51 PM

The C++ standard. Its a minor point, but the implementation (i.e. the compiler) has some identifiers beginning with a underscore reserved, like so:

Begins with two underscores - always reserved

Beginw with an underscore followed by a capital letter - always reserved

Begins with an underscore - reserved in global scope

Most compilers are quite conservative, they will only use identifiers from the first two, but think of how many people use __HEADER_GUARD__ or _HEADER_GUARD, rather than something like HEADER_GUARD_H.

TheBuzzSaw

Mar 28, 2010 at 12:56 PM

I prefix my private/protected member variables with an underscore.

It is good to follow syntax standards, but naming conventions standards are completely subjective. Everywhere I go, the standard is different, so I feel no remorse in violating the underscore "rule".

_the_phantom_

Mar 28, 2010 at 1:02 PM

On my personal projects I forego all pre and post fixes on variable names; I tend towards writing short functions and as such the idea of 'confusing' what things could be what is low to non-existant. I've also recently enabled the 'bold local variables' option in VAX which pretty much makes it impossible.

At work we use something vaguely like Hungarian notation which is a pain as I dislike the noise at the best of times, however as my co-workers seem to be monkeys at times and we have to work with some poor tools this does make mistake less likely.

Example of my code;

typedef std::function<void (ID3D11DeviceContext*)> deferredFunction_t;struct RendererCommand{	RendererCommand() : cmdID(EDrawingCommand_NOP), cmd(NULL), time(0) {};	RendererCommand(DrawingCommandType cmdID, ID3D11CommandList * cmd, DWORD time);	RendererCommand(DrawingCommandType cmdID, const deferredFunction_t &function, DWORD time);	RendererCommand(const RendererCommand &rhs);	~RendererCommand();	DrawingCommandType cmdID;	ID3D11CommandList * cmd;	deferredFunction_t deferredFunction;	DWORD time;};class RenderingAgent : public Concurrency::agent{public:	RenderingAgent(Concurrency::ISource<RendererCommand>& commandList, Concurrency::ITarget<int> &completionNotice);	virtual ~RenderingAgent();	void SetupD3D(HWND window, bool singleThread);	void ProcessCommand(RendererCommand &command);protected:	void run();private:	Concurrency::ISource<RendererCommand> &commandList	Concurrency::ITarget<int> &completionNotice	HWND window;	bool shouldQuit;	int numDrawCalls;	bool singleThread;};

void RenderingAgent::run(){	SetupD3D11(window);	Concurrency::send(completionNotice, 1);	shouldQuit = false;	numDrawCalls = 0;	while(!shouldQuit)	{		RendererCommand command = Concurrency::receive(commandList);		ProcessCommand(command);	}	RendererCommand command;	while(try_receive(commandList, command))	{		if(command.cmd)			command.cmd->Release();	}	ShutDownD3D();	done();}void RenderingAgent::ProcessCommand(RendererCommand &command){	HRESULT res = S_OK;	switch(command.cmdID)	{	case EDrawingCommand_Quit:		shouldQuit = true;		break;	case EDrawingCommand_Present:		res = g_pSwapChain->Present(1, 0);		if(!singleThread)			Concurrency::asend(completionNotice, numDrawCalls);		numDrawCalls = 0;		break;	case EDrawingCommand_Function:		command.deferredFunction(g_pImmediateContext);		numDrawCalls++;		break;	case EDrawingCommand_Render:		if(command.cmd)		{			g_pImmediateContext->ExecuteCommandList(command.cmd, FALSE);			command.cmd->Release();			numDrawCalls++;		}		break;	case EDrawingCommand_NOP:		if(!singleThread)			Concurrency::asend(completionNotice, 1);		break;	case EDrawingCommand_Waiting:		break;	default:		shouldQuit = shouldQuit;		break;	}}

Two points;
1) no, the 'shouldQuit = shouldQuit' in the default case isn't an error, I was testing something and I'm as yet to remove it
2) the g_pSwapChain and g_pImmediateContext were lifted from a DX11 example and I've just not refactored the code yet [grin]

iMalc

Mar 28, 2010 at 1:06 PM

There's a difference between what simply works for you in a particular situation, and what is part of the C++ standard.
Someone's sig has something like: If you walk barefoot on the broken glass of undefinied behaviour, then you've got to expect the occasional cut.
I.e. You've got to expect that if you update your compiler or use a different compiler altogether, or even just change some compile flags, then it might not work any more.

Zakwayda

Mar 28, 2010 at 1:08 PM

Quote:
What standard?
It worked for me in C/C++ and C# + Java, and I've been a pro game programmer for over 14 years now :)

I imagine one could program for 14 years without it causing any problems, just due to the relatively low probability of a symbol clash occurring. However, it's always good to know what the 'rules' are according to the standard (IMO), and I have read a few anecdotes online about this tripping people up.

Anyway, member variables starting with an underscore followed by a lower-case letter should be ok, IIRC. As for other conventions (such as header guards that start with one or more underscores followed by a capital letter), my own view is that even if the probability of a symbol clash with something in the standard library is low, you might as well just follow the standard and cut that probability down to zero.

owl

Mar 28, 2010 at 1:33 PM

Using m_ to identify member variables can be handy. It allows you to name function parameters and local variables without having to worry about confusing them with member ones. Using c before the class name lets you call the instances by the name of the object the class is supposed to represent.

class ccar{   private:      std::string m_model;   public:      void setModel(std::string model) {m_model=model;}};ccar car;car.setModel("stuff");

In an example like this it looks superfluous but when you have 20 classes with lots of variables each, it does help.

Zakwayda

Mar 28, 2010 at 1:50 PM

Quote:
Using m_ to identify member variables can be handy. It allows you to name function parameters and local variables without having to worry about confusing them with member ones.

Those who advocate for not using prefixes might say that you can use this-> to resolve ambiguities where they occur. (Although, I have to admit I've been bitten by this before - forgetting a 'this->' can lead to interesting bugs. It's easy enough to track these down using the debugger though.)

Quote:
Using c before the class name lets you call the instances by the name of the object the class is supposed to represent.
class ccar{   private:      std::string m_model;   public:      void setModel(std::string model) {m_model=model;}};ccar car;car.setModel("stuff");
In an example like this it looks superfluous but when you have 20 classes with lots of variables each, it does help.

Coding style is just personal preference, etc., etc., but I have to say I've never seen it done this way. It's pretty typical for class names to be CamelCase, in which case you can just write:

Car car;

I think I've heard some argue that symbols shouldn't be distinguished by case only, although I'm not sure what the rationale behind this is; C++ is, after all, a case-sensitive language.

Also, ccar looks pretty odd to me - even more odd than CCar. (Plus, I'm one of those folks that questions the use of 'c' prefixes for class names.)

Again though, it doesn't really matter - if you're working with others, you'll most likely be following a set of existing guidelines, and if you're working by yourself, you can do whatever the heck you want :)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.