Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > nomenclature

Reply
Thread Tools

nomenclature

 
 
bob smith
Guest
Posts: n/a
 
      10-02-2012
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;

}
 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      10-02-2012
On 10/2/2012 3:51 PM, 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;
>
> }


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


 
Reply With Quote
 
 
 
 
Daniel Pitts
Guest
Posts: n/a
 
      10-02-2012
On 10/2/12 12:51 PM, 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.

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


 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      10-02-2012
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/ja...nv-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
 
Reply With Quote
 
Daniel Pitts
Guest
Posts: n/a
 
      10-02-2012
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/ja...nv-138413.html


Thanks for the link Lew. That matches in general what my specific
example showed
 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      10-02-2012
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.



 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      10-02-2012
On 10/2/2012 3:51 PM, 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;
>
> }


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
http://www.velocityreviews.com/forums/(E-Mail Removed)d
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      10-03-2012
On Tue, 2 Oct 2012 12:51:05 -0700 (PDT), bob smith
<(E-Mail Removed)> 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.


 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      10-05-2012
Eric Sosman <(E-Mail Removed)> 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.


 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      10-06-2012
On 10/5/2012 12:38 PM, Andreas Leitgeb wrote:
> Eric Sosman <(E-Mail Removed)> 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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
OT: Killfile nomenclature Keith Thompson C Programming 2 01-06-2009 09:28 PM
stack addressing & type nomenclature bill C Programming 11 08-21-2005 11:01 PM
class definition - namespace nomenclature clarification Karthik Kumar C++ 2 09-15-2004 03:58 PM
size and nomenclature of integral types Shailesh C++ 4 04-04-2004 06:37 AM
nomenclature issue Mantorok Redgormor C Programming 24 02-01-2004 10:23 PM



Advertisments