Poll: What to name constructor variables

Started by
47 comments, last by pex22 19 years, 7 months ago
Quote:Original post by David ONeil
It places emphasis on the variable name, rather than the fact that it is a class member, by placing the 'C' at the end, and this makes it easier to follow code for me.
If it works for you, that's great, but I'll just point out that the very first thing I saw when looking at your code was a great big 'C' tacked onto the end of some variable, and thus the emphasis, in my eyes, was still on the fact that it was a member variable. But that's probably just because I'm not used to it. The 'm' the prefix my member variables just sorta disappears when I read the variable name, since I'm use to it. But maybe it doesn't to you... Whatever. [smile]
"We should have a great fewer disputes in the world if words were taken for what they are, the signs of our ideas only, and not for things themselves." - John Locke
Advertisement
We always do it this way:
class cPoint{public:  cPoint(cInt x, cInt y, cInt size) :    X(x),    Y(y),    Size(size)  {}protected:  cInt X;  cInt Y;  cInt Size;};

No prefixes, no underscores, no name conflicts and you can easily distinguish between attributes and parameters:).
We don't need any kind of "g_" prefix since we don't use any globals:D

[Edited by - MickeyMouse on September 17, 2004 2:08:09 AM]
Maciej Sawitus
my blog | my games
Quote:Original post by MrPoopypants
I generally do:

*** Source Snippet Removed ***

I usually keep all constructor variables as brief as possible, and all variables within the class in all caps... Works very well for me. I mainly code in Java, but I do the same in C/C++.


ALL CAPS in C or C++ means it's a macro, you shouldn't name variables (or anything other than a macro) in all caps.
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
Quote:Original post by Emmanuel Deloget
Hello everybody,

When it comes to giving a name to a type, a member variable, any identifier, I usually use the "it depends" convention.

For example, If I do a GTK+ program I will never call a function MyFunctionThatDoesEverything(). I will probably name it "myprogprefix_my_function_that_does_everything()". When I do a MFC program my classes name are prefixed with "C" and my member variables are prefixed with "m_" - in order to match the MFC coding convention, and thus giving a more coherent look and feel to my code. If I define a new structure in a Win32 API program, I will probably name it with caps (just like POINT, SIZE, BITMAPINFO and so on). When I create a separate library, I only prefix my member variables with a single "_".

It is not that important in fact. The more important thing is to document the coding convention and to respect it through your whole program. Every people that works on your code can read the coding convention document. This makes the program easier to read.

Regards,


I disagress with this for the reasons you just gave for using various naming styles (when in Rome...). If I write an stl-like container, it's actually semantically important to name things accordingly (the typedef is iterator *not* Iterator as many coding conventions would have you write).
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
Quote:Original post by jdhardy
Quote:Original post by Sneftel
Quote:Original post by Agony
Does that actually work? With the " : x(x), y(y)" initializer list thing going on?
Yes it does. Since initializer lists only initialize member variables, those are the only variables in scope when resolving the target to be initialized. However, the argument to each constructor follows normal resolution rules, so local variables take precedence over member variables.
I'll add that to the list of things I wish I had known months ago. Thank you.

As will I. Makes sense in retrospect. I was using initializer lists anyways...

also to the OP: variables prefixed with underscores are reserved. If you need a variable like that, POSTfix it. Aka: var_ instead of _var.
This may be ugly but in the very often occuring scenario you mentioned I do:

Constructor(int xx, int yy, int zz){x = xx; y = yy; z = zz;}


Dont worry Id never do triplets;)

I dont like m_x because the member variable is what im going to be working with through out the code, so I want that as intuitive and short as possible, hence 'x'.
The arguments are a one time thing.

-CProgrammer
Quote:Original post by CProgrammer
Constructor(int xx, int yy, int zz){x = xx; y = yy; z = zz;}



This would be better written as:

Constructor(int x, int y, int z) : x(x) , y(y) , z(z) {}


as previously mentioned in this thread. You could also consider postfixing your variables with underscores: x_ y_ z_ as that method continues to work with longer variable names (I assume you don't type: array_size = array_sizearray_size;)
Quote:Original post by MaulingMonkey
Quote:Original post by CProgrammer
Constructor(int xx, int yy, int zz){x = xx; y = yy; z = zz;}



This would be better written as:

Constructor(int x, int y, int z) : x(x) , y(y) , z(z) {}


as previously mentioned in this thread. You could also consider postfixing your variables with underscores: x_ y_ z_ as that method continues to work with longer variable names (I assume you don't type: array_size = array_sizearray_size;)


However, the doubling method still works for member functions, such as setxyz(in xx, int yy, int zz), etc. I use this if I haven't used any m_ prefixes.
i use uppercases when i cant use lowercases, like this:
Sound::Sound(device* Device,int number){  pDevice = Device; // can't use 'device'  iNumber = number; // but i prefer using lowercases for variables, like this:  automate = 0; // instead of NULL};
pex.

This topic is closed to new replies.

Advertisement