nomenclature

[bob smith]

Is this sort of thing bad practice (using parameter names that are the same as my field names in the constructor)?



public My_Rectangle(double x, double y, double width, double height) {
this.x=x;
this.y=y;
this.width=width;
this.height=height;

}

 

[Arne Vajhøj]

Is this sort of thing bad practice (using parameter names that are the same as my field names in the constructor)?

public My_Rectangle(double x, double y, double width, double height) {
this.x=x;
this.y=y;
this.width=width;
this.height=height;

}

We can discuss whether it looks good or bad.

But it is very widely used, so any Java developer should
understand it.

Some IDE's even generate constructor code looking like
that.

Arne

 

[Daniel Pitts]

Is this sort of thing bad practice (using parameter names that are the same as my field names in the constructor)?



public My_Rectangle(double x, double y, double width, double height) {
this.x=x;
this.y=y;
this.width=width;
this.height=height;

}

If you are considering objecting because it requires "this.", I actually
find that to be a useful syntax, and my constructors (and setters) use
it, even if there isn't a name collision with local symbols.

Most experienced Java programmers will take more exception with the
class name. Java convention would suggest MyRectangle, not My_Rectangle.

I've seen people try to avoid "name collisions", with ugly results.
Underscores before members, or before parameters, or other such
conventions. Ugly... ugly.

 

[Lew]

If you are considering objecting because it requires "this.", I actually
find that to be a useful syntax, and my constructors (and setters) use
it, even if there isn't a name collision with local symbols.

Most experienced Java programmers will take more exception with the
class name. Java convention would suggest MyRectangle, not My_Rectangle.
http://www.oracle.com/technetwork/java/codeconv-138413.html

I've seen people try to avoid "name collisions", with ugly results.
Underscores before members, or before parameters, or other such
conventions. Ugly... ugly.

 

[Daniel Pitts]

http://www.oracle.com/technetwork/java/codeconv-138413.html

Thanks for the link Lew. That matches in general what my specific
example showed ;-)

 

[markspace]

Is this sort of thing bad practice

public My_Rectangle(double x, double y, double width, double height) {

The arguments are fine, but the underscore in the ctor name isn't
considered proper coding convention for Java.

 

[Eric Sosman]

Is this sort of thing bad practice (using parameter names that are the same as my field names in the constructor)?



public My_Rectangle(double x, double y, double width, double height) {
this.x=x;
this.y=y;
this.width=width;
this.height=height;

}

It makes good sense to me. I don't need to invent two different
names for the same thing:

private final double x, y, width, height;
public MyRectangle(double top, double left,
double wide, double tall) {
x = top;
y = left;
width = wide;
height = tall;
}

Also, if the names agree I'm less likely to make the kind of
silly error shown above. (Did you spot it on the first reading?)

Keep in mind that the parameter names used for non-private
methods and constructors are as much a part of the interface as
are the method names themselves. They're visible in the Javadoc,
and are probably visible when an IDE auto-suggests or even auto-
generates code. So you don't just need names, you need good
names. If you then insist on using different names for the fields,
you may wind up giving the good names to the clients and forcing
the implementor to suffer with less-good names. Some people get
around this by inventing one good name and then altering it:

private final double _goodName;
public Thing(double goodName) {
_goodName = goodName;
}

.... but to my eye this is awkward and ugly. YMMV.

 

[Roedy Green]

public My_Rectangle(double x, double y, double width, double height) {
this.x=x;
this.y=y;
this.width=width;
this.height=height;

This is Sun standard practice.

 

[Andreas Leitgeb]

private final double _goodName;
public Thing(double goodName) {
_goodName = goodName;
}

I admit using a "m_" prefix on fields:
private final double m_goodName;
public Thing(double goodName) {
m_goodName = goodName;
}

I got into that habit in my early days of C++ with (gasp)
some Microsoft IDE. I'm not completely following that
style, though, as I typically don't use type-hints after
the underscore.

Sometimes I even do that, like when I think that goodName
looks strange, but xGoodName looks much less strange. Also,
when there is a goodName for some item, but two different
representations for it, then I might do something roughly
like:

private int m_iGoodName;
private String m_sGoodName;
public void setGoodName(int iGoodName) {
m_iGoodName=iGoodName;
m_sGoodName=""+iGoodName;
}
public void setGoodName(String sGoodName) {
m_sGoodName=sGoodName;
m_sGoodName=Integer.parseInt(sGoodName);
}

I guess you now feel like asking what name (and type) I use
for the getter, but that's beyond the scope of the example.
;-)

 

[Arne Vajhøj]

I admit using a "m_" prefix on fields:
private final double m_goodName;
public Thing(double goodName) {
m_goodName = goodName;
}

I got into that habit in my early days of C++ with (gasp)
some Microsoft IDE. I'm not completely following that
style, though, as I typically don't use type-hints after
the underscore.

The special Win32 flavor of hungarian notation.

Arne