How do you guys name the parameters of constructing methods?

[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?

[Salt_Peter]

On Dec 18, 4:39 pm, xz <[e-mail]:

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

[Victor Bazarov]

xz wrote:

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[s]
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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[xz]

On Dec 18, 3:49 pm, "Victor Bazarov" <[e-mail]:

xz wrote:

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.

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[s]
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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Rolf Magnus]

Victor Bazarov wrote:

> 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:

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)
{
}

[Jim Langston]

xz wrote:

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]

--
Jim Langston
ta*******@rocketmail.com

[Kira Yamato]

On 2007-12-18 16:39:52 -0500, xz <zh*********@gmail.comsaid:

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?

--

-kira

[Andre Kostur]

"Victor Bazarov" <v.********@comAcast.netwrote in news:fk9f9f$gag$1
@news.datemas.de:

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

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

[Ioannis Gyftos]

On Dec 19, 9:20 am, Andre Kostur <[e-mail]:

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.

[Kira Yamato]

On 2007-12-19 02:45:55 -0500, Ioannis Gyftos <io************@gmail.comsaid:

On Dec 19, 9:20 am, Andre Kostur <[e-mail]:

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

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. :)

--

-kira

[James Kanze]

On Dec 19, 12:56 am, Rolf Magnus <[e-mail]:

Victor Bazarov wrote:

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:

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?

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)
{
}

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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Default User]

Rolf Magnus wrote:

Victor Bazarov wrote:

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.

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

[peter koch]

On 19 Dec., 08:20, Andre Kostur <[e-mail]:

"Victor Bazarov" <[e-mail] in news:fk9f9f$gag$1
@news.datemas.de:

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.

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

[Default User]

peter koch wrote:

On 19 Dec., 08:20, Andre Kostur <[e-mail]:

"Victor Bazarov" <[e-mail] in
news:fk9f9f$gag$1 @news.datemas.de:

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.

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

[James Kanze]

On Dec 19, 11:41 pm, "Default User" <[e-mail]:

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:-).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Default User]

James Kanze wrote:

On Dec 19, 11:41 pm, "Default User" <[e-mail]:

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.

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

[James Kanze]

On Dec 20, 6:16 pm, "Default User" <[e-mail]:

James Kanze wrote:

On Dec 19, 11:41 pm, "Default User" <[e-mail]:

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.

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.

There's also the problem of how you pronounce it.

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

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]