How do you guys name the parameters of constructing methods?

X

xz

For example, I have a Class Date with internal variable year, month
and day.
In Java I would write:

class Date{
int year;
int month;
int day;
Date(int year, int month, int day) {
this.year = year;
this.month = month;
this.day;
}
}

That is, simply name every parameter as what it is and use this.*
within the method body to differentiate the class variables and the
parameters.

However, in C++ it seems I cannot do this. In this particular
example, probably I can write:

Date::Date(int y, int m, int d): year(y), month(m), day(d) {
}

However, the letters "y", "m" or "d" are not that informative. Thus I
don't really like this naming style.
Is there a better way to do this?
What would you guys use to replace "y", "m" and "d" in this case?
 
S

Salt_Peter

For example, I have a Class Date with internal variable year, month
and day.
In Java I would write:

class Date{
int year;
int month;
int day;
Date(int year, int month, int day) {
this.year = year;
this.month = month;
this.day;
}

}

That is, simply name every parameter as what it is and use this.*
within the method body to differentiate the class variables and the
parameters.

However, in C++ it seems I cannot do this. In this particular
example, probably I can write:

Date::Date(int y, int m, int d): year(y), month(m), day(d) {

}

However, the letters "y", "m" or "d" are not that informative. Thus I
don't really like this naming style.
Is there a better way to do this?
What would you guys use to replace "y", "m" and "d" in this case?

There is no right way, its a question of style.

class Date
{
int m_year; // members
int m_month;
int m_day;
public:
Date() : m_year(2000), m_month(1), m_day(1)
{ }
Date(int year, int month, int day): m_year(year),
m_month(month),
m_day(day)
{ }
};

or use year_ and year but prefereably not _year
 
V

Victor Bazarov

xz said:
For example, I have a Class Date with internal variable year, month
and day.
In Java I would write:

class Date{
int year;
int month;
int day;
Date(int year, int month, int day) {
this.year = year;
this.month = month;
this.day;
}
}

In C++ you'd do

class Date {
int year;
int month;
int day;
public: // you probably meant that
Date(int year, int month, int day)
: year(year), month(month), day(day) {}
};
That is, simply name every parameter as what it is and use this.*
within the method body to differentiate the class variables and the
parameters.

Same with C++. You need 'this->' to differenciate.
However, in C++ it seems I cannot do this.

Is that so? Post the complete compilable code and the error message
you get.
In this particular
example, probably I can write:

Date::Date(int y, int m, int d): year(y), month(m), day(d) {
}

However, the letters "y", "m" or "d" are not that informative. Thus I
don't really like this naming style.
Is there a better way to do this?

See above.
What would you guys use to replace "y", "m" and "d" in this case?

I've seen (and used) the convention to follow the argument names with
an underscore:

Date(int year_, int month_, int day_)
: year(year_), month(month_), day(day_) {}

Or (I know some cringe at a mere sight of it) just name your members
with a prefix (like 'm_'), arguments and local variables - without
prefices. It's easy to discern what is a member and what isn't.


V
 
X

xz

In C++ you'd do

class Date {
int year;
int month;
int day;
public: // you probably meant that
Date(int year, int month, int day)
: year(year), month(month), day(day) {}
};


Same with C++. You need 'this->' to differenciate.
Now I know what was wrong. "this" in C++ is pointer instead of
reference so that you have to use "this->" instead of "this."
thanks!
However, in C++ it seems I cannot do this.

Is that so? Post the complete compilable code and the error message
you get.
In this particular
example, probably I can write:
Date::Date(int y, int m, int d): year(y), month(m), day(d) {
}
However, the letters "y", "m" or "d" are not that informative. Thus I
don't really like this naming style.
Is there a better way to do this?

See above.
What would you guys use to replace "y", "m" and "d" in this case?

I've seen (and used) the convention to follow the argument names with
an underscore:

Date(int year_, int month_, int day_)
: year(year_), month(month_), day(day_) {}

Or (I know some cringe at a mere sight of it) just name your members
with a prefix (like 'm_'), arguments and local variables - without
prefices. It's easy to discern what is a member and what isn't.

V
 
R

Rolf Magnus

Victor said:
See above.


I've seen (and used) the convention to follow the argument names with
an underscore:

And I've seen (and used) the convention to do exactly that with the member
variables instead of the parameters.
Date(int year_, int month_, int day_)
: year(year_), month(month_), day(day_) {}

Or (I know some cringe at a mere sight of it) just name your members
with a prefix (like 'm_'), arguments and local variables - without
prefices. It's easy to discern what is a member and what isn't.

Another possibility is to name the parameters different in the header than
in the implementation, i.e.:

// header
class Date
{
public:
Date(int year, int month, int day);
};

// implementation
Date::Date(int y, int m, int d)
: year(y), month(m), day(d)
{
}
 
J

Jim Langston

xz said:
For example, I have a Class Date with internal variable year, month
and day.
In Java I would write:

class Date{
int year;
int month;
int day;
Date(int year, int month, int day) {
this.year = year;
this.month = month;
this.day;
}
}

You can do it that way if you use an initialization list.

class Date
{
public:
Date( int year, int month, int day ): year(year), month(month), day(day)
{}
private:
int year;
int month;
int day;
};

Personally, however, I would do it this way:

class Date
{
public:
Date( int Year, int Month, int Day ): Year_( Year ), Month_( Month ),
Day_( Day ) {}
int Year() { return Year_; }
void Year( int Year ) { Year_ = Year; }
int Month() { return Month_; }
void Month( int Month ) { Month_ = Month; }
int Day() { return Day_; }
void Day( int Day ) { Day_ = Day; }
};

Some poople don't like the use of any time of prefix or suffix but
differentiate with use of capital letters or not. Personally, I think the
use of a suffix of _ is more clear.

[SNIP]
 
K

Kira Yamato

For example, I have a Class Date with internal variable year, month
and day.
In Java I would write:

class Date{
int year;
int month;
int day;
Date(int year, int month, int day) {
this.year = year;
this.month = month;
this.day;
}
}

That is, simply name every parameter as what it is and use this.*
within the method body to differentiate the class variables and the
parameters.

However, in C++ it seems I cannot do this. In this particular
example, probably I can write:

Date::Date(int y, int m, int d): year(y), month(m), day(d) {
}

However, the letters "y", "m" or "d" are not that informative. Thus I
don't really like this naming style.
Is there a better way to do this?
What would you guys use to replace "y", "m" and "d" in this case?

I see no problem with your parameter-naming style at all. In fact,
that is what I would do too.

There is no superfluous and ugly prefixes or subfixes. Your only
complain is the single-letter variable names. However, for local
variables in a short function, short variable names are preferred.
Afterall, how many local variables or how confusing can 50 lines of
code be?
 
A

Andre Kostur

See above.


I've seen (and used) the convention to follow the argument names with
an underscore:

Date(int year_, int month_, int day_)
: year(year_), month(month_), day(day_) {}

Or (I know some cringe at a mere sight of it) just name your members
with a prefix (like 'm_'), arguments and local variables - without
prefices. It's easy to discern what is a member and what isn't.

I've been using a 'p_' prefix to the parameters:

Date(int p_year, int p_month, int p_day)
: year(p_year), month(p_month), day(p_day) {}

Gives you a nice reminder that you're dealing with the parameter, and not
the member variable. Although I only add the p_ when there is a name
"conflict".
 
I

Ioannis Gyftos

Gives you a nice reminder that you're dealing with the parameter, and not
the member variable. Although I only add the p_ when there is a name
"conflict".

Or misguides an uninvolved guy looking at your code (ie, me) to think
that it represents a pointer :) I think "m_" is more widely
recognized.
 
K

Kira Yamato

Or misguides an uninvolved guy looking at your code (ie, me) to think
that it represents a pointer :) I think "m_" is more widely
recognized.

Or maybe we should just do away with prefixes and suffixes, and just
use italic or bold or even colors.

Oh wait, I think some IDE's may actually do this already. :)
 
J

James Kanze

And I've seen (and used) the convention to do exactly that
with the member variables instead of the parameters.

Not much better. Names should be meaningful. What does _ mean?
Another possibility is to name the parameters different in the
header than in the implementation, i.e.:
// header
class Date
{
public:
Date(int year, int month, int day);
};
// implementation
Date::Date(int y, int m, int d)
: year(y), month(m), day(d)
{
}

I don't like that either.

I don't think that there is one univeral convention that covers
everything. If the class is really just a structure with
constructors (but public data members), I'll use the same name
for the parameters and the members. If the class is mutable, it
would make sense (both in C++ and in Java) to name the
parameters "initialYear", etc. If the data members are private,
prefixing them with my works well for me. (Again, this
convention applies to Java as well as to C++.) Other conditions
are also possible. Just don't start or end names with an
underscore---it's too ugly.
 
M

Michael DOUBEZ

xz a écrit :
For example, I have a Class Date with internal variable year, month
and day.
In Java I would write:

class Date{
int year;
int month;
int day;
Date(int year, int month, int day) {
this.year = year;
this.month = month;
this.day;
}
}

That is, simply name every parameter as what it is and use this.*
within the method body to differentiate the class variables and the
parameters.

However, in C++ it seems I cannot do this. In this particular
example, probably I can write:

Date::Date(int y, int m, int d): year(y), month(m), day(d) {
}

However, the letters "y", "m" or "d" are not that informative. Thus I
don't really like this naming style.
Is there a better way to do this?
What would you guys use to replace "y", "m" and "d" in this case?

You could use type naming:

struct Day
{
int value;

Day(int day):value(day){}
};

struct Month
{
int value;

Month(int month):value(month){}
};


struct Year
{
int value;

Year(int year):value(year){}
};


class Date{
int year;
int month;
int day;

public:
Date(const Year& y, const Month& m, const Day& d):
year(y.value),month(m.value),day(d.value){}
};

And then
Date today(Year(2007),Month(12),Day(19));
or
Date tomorrow(2007,12,20);

That way, the declaration is meaningful. If you want to add security,
you can still make the constructor explicit in order to force the form
used for 'today'.

Michael
 
K

Kira Yamato

xz a écrit :

You could use type naming:

struct Day
{
int value;

Day(int day):value(day){}
};

struct Month
{
int value;

Month(int month):value(month){}
};


struct Year
{
int value;

Year(int year):value(year){}
};


class Date{
int year;
int month;
int day;

public:
Date(const Year& y, const Month& m, const Day& d):
year(y.value),month(m.value),day(d.value){}
};

And then
Date today(Year(2007),Month(12),Day(19));
or
Date tomorrow(2007,12,20);

That way, the declaration is meaningful. If you want to add security,
you can still make the constructor explicit in order to force the form
used for 'today'.

Good idea.

You can even add more constructors for Month like
explicity Month(const string &m);
so that you can declare
Date today(Year(2007), Month("December"), Day(19));
too.

So, essentially, you let the *type* say what the variable is so that
the name of the variable becomes less of a matter. This works
particularly well for local variables in small functions.
 
M

Michael DOUBEZ

Kira Yamato a écrit :
Good idea.

You can even add more constructors for Month like
explicity Month(const string &m);
so that you can declare
Date today(Year(2007), Month("December"), Day(19));
too.

So, essentially, you let the *type* say what the variable is so that the
name of the variable becomes less of a matter. This works particularly
well for local variables in small functions.


This work very well if you want to ensure you parameters are given in
the right order for some tricky functions.

Relevant example is with using memcpy(). Instead of defining:
void *memcpy (void *dest, const void *src, size_t n);

You define:
struct DestPtr
{
void* value;
explicit DestPtr(void* v):value(v){}
};
struct SrcPtr
{
void* value;
explicit SrcPtr(void* v):value(v){}
};

and then
inline
void* memcpy_secure(const DestPtr& dest, const SrcPtr& src,size_t n)
{
return memcpy(dest.value,src.value,n);
}

So that if you mix parameters (to take an example from the air, you
change from a call to bcopy to a call to memcpy):

memcpy_secure(SrcPtr(foo),DestPtr(bar),42);

You get an error instead of spending hours trying to locate a stupid
hard-to-find bug that may corrupt your stack among other things.

Michael
 
D

Default User

Rolf said:
Victor Bazarov wrote:

And I've seen (and used) the convention to do exactly that with the
member variables instead of the parameters.


My company's model coding standard requires that:

Rule 45a - A class data member shall have a trailing underscore.
Placing an underscore at the end of a class attribute allows you to
easily determine where all the class attributes are being used in the
code. In the example below, including the underscore makes it easier
to understand the code in the contructor's initializer list.

[example skipped]






Brian
 
P

peter koch

@news.datemas.de:










I've been using a 'p_' prefix to the parameters:

Date(int p_year, int p_month, int p_day)
: year(p_year), month(p_month), day(p_day) {}

Gives you a nice reminder that you're dealing with the parameter, and not
the member variable. Although I only add the p_ when there is a name
"conflict".

I like that rule and use it myself. As does James Kanze, I believe
that the trailing underscore is just to ugly.

/Peter
 
D

Default User

peter said:
I like that rule and use it myself. As does James Kanze, I believe
that the trailing underscore is just to ugly.

Matter of opnion. Personally, I don't mind the trailing underscore, but
that leading p_ is horrible. In fact, anything attached to the front of
a variable is, to my mind, a means of reducing readability.





Brian
 
J

James Kanze

Matter of opnion. Personally, I don't mind the trailing underscore,

It's not just a problem of esthetics. An underscore is not
particularly visible, and a trailing (or leading) underscore is
even less visible. If the name is the last symbol on the line,
it can easily be overlooked.

There's also the problem of how you pronounce it.
but that leading p_ is horrible. In fact, anything attached to
the front of a variable is, to my mind, a means of reducing
readability.

It depends on the rest of the convention. To start with, of
course, standard English usage is to put the modifier before
what it modifies, so you will almost always have something
"attached" to the front of a variable name (since variable names
should be qualified nouns). Something like "currentState",
rather than just "State" (which would be the name of the type).
I don't think that this is what you're talking about, however,
but used rigorously, it probably would obliviate the need for
any other indicators. In practice, I've found that some sort of
convention helps for member variables (and only member
variables). I use "my" (and "our" for static members) because
they *are* qualifiers. But if a client prefers m_ (and s_), it
doesn't bother me too much---since I just treat it as a special
spelling of "my" and "our", and pronounce it like that in my
head:).
 
D

Default User

James said:
It's not just a problem of esthetics. An underscore is not
particularly visible, and a trailing (or leading) underscore is
even less visible. If the name is the last symbol on the line,
it can easily be overlooked.

That's your opinion. I don't have that problem.
There's also the problem of how you pronounce it.

When it's necessary to disambiguate a variable in conversation, we find
a way. It rarely comes up.




Brian
 
J

James Kanze

That's your opinion. I don't have that problem.

It's not really just an opinion; it's base on sound typological
principles. How serious the problem is will depend on the fonts
you are using. If the font displays the underscore three points
thick, for example, it's certainly not going to be overlooked.
Most fonts, at least most fonts I use, display it as a very,
very fine line well below the baseline. Where it isn't readily
apparent. (At least one font I've used put it so far below the
baseline that it merged with the top of capital letters on the
line below.) This is consistent with it's usual uses:
underlining text, or replacing a space in a context where a
space would be illegal.
When it's necessary to disambiguate a variable in
conversation, we find a way.

One can always find a way.
It rarely comes up.

You don't discuss your code enough with collegues:).

Ideally, you shoud be able to discuss code over the telephone
with no need of meta information, just by applying the coding
guidelines to the pronounced symbol names. It is a ideal that
is, admittedly, rarely fully met---in particular, typenames and
variable names often only differ by the capitalization of their
first letter. (This violates another rule: that the edit
distance between any two symbols should be at least 2, so that a
single typo won't result in one symbol being interpreted as
another. This is perhaps less critical when one of the symbols
is a type name, and the other not, because such
misinterpretations will almost certainly cause a compiler error
anyway.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top