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]

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

[Patricia Shanahan]

Often, there is one right name for a property, like "width" for the
width of a rectangle. That is both the best possible identifier for a
private field representing the property, and the best possible
identifier for a constructor argument setting its value.

Why give one of them a different, necessarily inferior, identifier?

Patricia

[Daniel Pitts]

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]

Daniel Pitts wrote:
> bob smith wrote:
>> 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.

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.

--
Lew

[Daniel Pitts]

bob smith wrote:
>>> public My_Rectangle(double x, double y, double width, double height) {

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

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

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

[markspace]

On 10/2/2012 12:51 PM, bob smith wrote:
> 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]

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.

--
Eric Sosman
eso...@ieee-dot-org.invalid

[Roedy Green]

On Tue, 2 Oct 2012 12:51:05 -0700 (PDT), bob smith
<b...@coolfone.comze.com> wrote, quoted or indirectly quoted someone
who said :

>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.
--
Roedy Green Canadian Mind Products http://mindprod.com
The iPhone 5 is a low end Rolex.

[Andreas Leitgeb]

Eric Sosman <eso...@ieee-dot-org.invalid> wrote:
> 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]

On 10/5/2012 12:38 PM, Andreas Leitgeb wrote:
> Eric Sosman <eso...@ieee-dot-org.invalid> wrote:
>> 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.

The special Win32 flavor of hungarian notation.

Arne