Poll: What to name constructor variables

Started by
47 comments, last by pex22 19 years, 7 months ago
Quote:Original post by Magmai Kai Holmlor
Quote:Original post by load_bitmap_file
EDIT: I just remembered that you can't say "this" in the constructor's initializer list! Still nifty though.


You can, you just have to be careful not to actually use it.


You may use this in the initializer list. The behavior of it is perfectly well defined. Since the initializer list is defined to be in the scope of the constructor, this can be used to reference to the object under construction safely. (12.6.2 - 7)

The only problems that could be encountered is when access a base class that has not been constructed yet. For instance, calling a virtual function when the object it applies is the object under construction, the function called is the one defined in the class under construction or one of it's bases, but not a function overriding it in a derived class from the constructor. (12.7 - 3)

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.

Advertisement
I generally do:

public class Circle{  private double BALL_X, BALL_Y, BALL_RADIUS;  public Circle( x , y , r){    BALL_X = x;    BALL_Y = y;    BALL_RADIUS = r;  }}


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++.
(0110101101000110)The Murphy Philosophy: Smile . . . tomorrow will be worse.
Quote:Original post by Washu
Quote:Original post by Magmai Kai Holmlor
Quote:Original post by load_bitmap_file
EDIT: I just remembered that you can't say "this" in the constructor's initializer list! Still nifty though.


You can, you just have to be careful not to actually use it.


You may use this in the initializer list. The behavior of it is perfectly well defined. Since the initializer list is defined to be in the scope of the constructor, this can be used to reference to the object under construction safely. (12.6.2 - 7)

The only problems that could be encountered is when access a base class that has not been constructed yet. For instance, calling a virtual function when the object it applies is the object under construction, the function called is the one defined in the class under construction or one of it's bases, but not a function overriding it in a derived class from the constructor. (12.7 - 3)


VS .NET 2003 was giving me a syntax error when I tried to use "this" in the initializer list:
A(int x)	:this->x(x){		}


Am I using it correctly? Does the "this" have to be implicit?

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++.


In C++ you generally don't want to name your variables IN ALL CAPS because that's typically reserved for macros, so you might run into some problems.
Quote:Original post by load_bitmap_file
Am I using it correctly? Does the "this" have to be implicit?

this is already implied on those variables. However, imagine a function call:
C::C(float x) : x(x), z(f(this->x)) ...

As you can see, if I had just said x, it clearly would have meant the x passed to the constructor. However, by using this->x I use the object x (whatever it may be).

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.

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 tend to use the "arg" prefix, with no underscore seperating, so a "radius" parameter would end up as "argRadius". I use this for any member function where the argument would create some naming ambiguity between member variables, not just constructors.
Quote:Original post by load_bitmap_file
Hmm.. I've seen that before but I've avoided it because I never felt it was necessary. Your point about the interface cleanliness over the implementation is new to me but certainly makes sense though. Thanks, I'll probably adopt the m_.

Along these lines, do you also prefix global variables with g_?


That's is the method I use. I got it while developing for windoze. It also help you differentiate between member variables and everything else.
[size="2"]I like the Walrus best.
Quote:Original post by load_bitmap_file
I wouldn't really classify the m_ and g_ as hungarian notation; the m_/g_ signify scope, not variable type.


That's a very important distinction.
Quote:Original post by MrPoopypants
I generally do:

public class Circle{  private double BALL_X, BALL_Y, BALL_RADIUS;  public Circle( x , y , r){    BALL_X = x;    BALL_Y = y;    BALL_RADIUS = r;  }}


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++.

This is not a good idea in C++, because variables are default initialised before you enter the constructor body, unless you provide an initialiser list (which you should). This is bad for two reasons: If the members have default constructors, you waste time by first default initialising them, then resetting them; if, on the other hand, they do not, then the program will not compile. Therefore, prefer initialiser lists.
2 cents

Lurking c++.comp.moderated I picked up the useful trick of not using 'get' and 'set' in the names of getter and setter functions. Simply use function overloading. With that in mind, Sneftel's useful advise blows up. For instance, you cannot do this:

class Var {   private:      int var;   public:      Var(int var) : var(var) { }      int var() { return var; }      var(int var) { var = var; }};int main() {   Var v(3);   v.var(4);   int t = v.var();   return 0;}


Therefore something must change. This change can be in either the variable names or the function names. It is useful to somehow designate class members, and that can be done with much less typing than using 'get' and 'set' in function names.

To me using underscores is a complete pain typing-wise, as hellz stated. Coding should be fun and as simple as possible. After much thought I settled upon the following:

int gVar; //Global vars are always gSomething.  An upper case          //letter will always follow the 'g'class Var {   private:      int varC;   public:      Var(int var) : varC(var) { }      int var() { return varC; }      var(int var) { varC = var; }};int main() {   gVar = 10;   Var v(3);   v.var(4);   int t = v.var();   return 0;}


That is the easiest to type I have seen. 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.

It may be a worthless 2 cents, but you are welcome to it.

This topic is closed to new replies.

Advertisement