stylistic use ofexplicit this.

[P.Hill]

This is a syntax style question, but hopefully not the usually silly
personal choice issues. I find myself use lots of explicit "this."
while most Java code has few to none explicit "this." uses.

Over the last couple of years I have spent some time programming in
languages other than Java. Some other languages do not have implicit
this, they always require explicit this.somevirtualMethod( ... )
Another influence upon my style is the commonality of code completion in modern
IDEs, so I find myself typing this. then looking for the needed completion.
Between these two influences I find myself writing "this." more if not
very often in my Java classes. I learned long ago that it is just simplier
to stick with the defacto standard, so everyones code reads the same.
Years ago in C I was a fan of aligned braces, these days I have no
problem running with the K&R brace style that came into Java, because
that is the Java-style.

I realize lots of "this." is not the typical Java style, but didn't think
anything of it until a co-worker said that when he sees an explicit "this."
it is stylistically saying to him that the writer wants to bring attention
to which method or member the code is using, otherwise
if it just another call, he doesn't expect to see "this.". I didn't get
into any great discussion with him about it, so I'm not sure even where
he might expect to use explicit "this.".

I checked into various style guides, but could find none that mention
stylistic use of explicit "this." for certain cases.

Does anyone have any comments on such a stylistic usage of explicit
"this.", such that you tend to insert it under certain conditions to help
to make the code clearer, or expect that a certain pattern is being used
when you see "this." or find it actually be confusing to see an explicit
"this."

I'd be interested in your comments.

-Paul

 

[Chris Smith]

Does anyone have any comments on such a stylistic usage of explicit
"this.", such that you tend to insert it under certain conditions to help
to make the code clearer, or expect that a certain pattern is being used
when you see "this." or find it actually be confusing to see an explicit
"this."

Well, it's a simple fact that 'this.method()' is more complex code than
'method()'. As such, I'd favor the latter unless there are definite
reasons otherwise. I wouldn't consider your experience with other
languages or quirks about how you use tools to be a definite reason,
since both are irrelevant to anyone maintaining your code.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[P.Hill]

P.Hill wrote:

Well, it's a simple fact that 'this.method()' is more complex code than
'method()'. As such, I'd favor the latter unless there are definite
reasons otherwise.

Okay, so Chris, you weigh in with a 'let's just keep it short as possible'.
This seems a fair enough choice. So given you don't use it in general,
do you ever? Are there any "this." constructs in your code?
What would be any of those 'reasons otherwise' which
would lead to specific coding patterns as eluded to by my co-worker and
suggested by you.

You are right in that how I got there is of no concern to the next programmer.
I only explained the reasons I was doing it to explain that I had
walked (wandered?) into the style not because I was so drawn by an clarity or
lack thereof, but that I had simply grown into it, one for it usefulness in
IDEs, the other because it is the expected form in other languages. Another way
to put it is that it wouldn't take much convincing to switch me back. While
starting down that path I had taken it as a benign choice -- that is until a
co-worker expressed his dislike of the style.

-Paul

 

[Chris Smith]

Okay, so Chris, you weigh in with a 'let's just keep it short as possible'.
This seems a fair enough choice. So given you don't use it in general,
do you ever? Are there any "this." constructs in your code?

I tend to use 'this.' to disambiguate as part of an idiomatic form in
mutator expressions:

public void setFoo(String foo)
{
this.foo = foo;
}

This isn't really good practice; just a habit of mine. It's
particularly important to avoid this form when the identifier gets
longer and thus more easily mistyped, because it can lead to silent
bugs. One of those differences between real life and best practice, I
guess.

Nevertheless, I still tend to use the basic form even when avoiding
duplicating the identifier, as in:

public void setFoo(String newVal)
{
this.foo = newVal;
}

Again, there's not a good reason to do this; but you asked what I do,
not what I think is good to do.

I don't think I ever use 'this.' in method invocation expressions. I
could imagine using 'OuterClass.this.someMethod()', though, to avoid
ambiguous method dispatch when programming with inner classes.

What would be any of those 'reasons otherwise' which
would lead to specific coding patterns as eluded to by my co-worker and
suggested by you.

I don't have specific examples. That's just a way of hedging, because I
know that I can't possibly predict every possible readability concern in
everyone else's code.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[P.Hill]

public void setFoo(String foo)
{
this.foo = foo;
}

I tend toward this also but not particularly for the reasons I gave for general
introduction of this. The modern IDEs (Eclipse and IntelliJ maybe others?)
all will tell me if I stupidly do:

public void setFoo(String fooooooooo)
{
this.foo = foo;
}

I don't think I ever use 'this.' in method invocation expressions. I
could imagine using 'OuterClass.this.someMethod()', though, to avoid
ambiguous method dispatch when programming with inner classes.

Hmm, I guess I wasn't even aware that I could skip the OuterClass.this
when working with inner classes and still expect it to find the outer
method.

-Paul

 

[Roedy Green]

This is a syntax style question, but hopefully not the usually silly
personal choice issues. I find myself use lots of explicit "this."
while most Java code has few to none explicit "this." uses.

I'm with you. If in doubt put in the explicit this, especially when
you are dealing with two different objects at once this one and some
other.

Another time you must use it is in constructors in them:

this.port = port;

Other times you might use it just to emphasise this a per object
variable where you might have expected it to be a common static per
class variable.


However, using it all the time is excessive. Most of the time it would
just be clutter.

 

[Roedy Green]

public void setFoo(String newVal)
{
this.foo = newVal;
}

that screws your JavaDoc.

 

[Dale King]

This is a syntax style question, but hopefully not the usually silly
personal choice issues. I find myself use lots of explicit "this."
while most Java code has few to none explicit "this." uses.

I don't really have a problem with it if it is used sparingly. It is much
better than using prefixes on member variables like some people do to
differentiate local variables from member variables. (e.g. m_variable to
indicate a member variable).

I agree with Chris that it should be used infrequently when it makes the
code clearer. I would not like to see it used on every variable or method
access.

 

[Mohun Biswas]

I'm with you. If in doubt put in the explicit this, especially when
you are dealing with two different objects at once this one and some
other.

Let's take it a little farther to a related style issue I've never seen
treated: let's say your class has private members foo and bar, and
therefore accessors getFoo() and getBar(). Now in some third method I
need the value of foo. My options include:

this.getFoo()
getFoo()
foo

In other words should a class access its own members via accessors or
directly? Directly makes debugging a little easier because most IDE's
let you click on the variable to see its value; running an accessor can
be done also but may take a couple more steps. But I can see where it
would make refactoring tougher.

MB

 

[P.Hill]

In other words should a class access its own members via accessors or
directly?

It can be better for future modification if even in the class it self
you use the accessor, but there is more than a few lines of my code that
accesses a classes members of itself directly.

But the debug question seems spurious, every debugger I've used shows
all members of an object in whatever is the variable window/view, but
I've never spent a lot of time with such new fangled features as hover
or click to see something. I usually drill to whatever I need in
the variable display -- the one that shows this, locals and other
variables.

-Paul

 

[Adam Maass]

This is a syntax style question, but hopefully not the usually silly
personal choice issues. I find myself use lots of explicit "this."
while most Java code has few to none explicit "this." uses.

In general: I use an explicit "this." when it will help disambiguate my
code.

Writing .equals methods is one place where the explicit "this" helps a lot.


-- Adam Maass

 

[Timo Kinnunen]

Let's take it a little farther to a related style issue I've never seen
treated: let's say your class has private members foo and bar, and
therefore accessors getFoo() and getBar(). Now in some third method I
need the value of foo. My options include:

this.getFoo()
getFoo()
foo

I use the last option normally. If I can't use an IDE with debugging
support and I need to see the changes, I'll convert my code to use
accessors. For this I introduce new private accessors.

private int foo;

becomes

private void foo(int value) { this.foo0 = value; }
private int foo() { return foo0; }

private int foo0;

For me, this affects readability the least. The change in the name of the
variable ensures that I won't miss any callsites.

 

[P.Hill]

In general: I use an explicit "this." when it will help disambiguate my
code.

Writing .equals methods is one place where the explicit "this" helps a lot.

Oh definitely! I had forgotten about this one.

if ( this.equals(that) ) {
...
}
is definitely the right construct.

if ( equals(that) ) {
....
}

is just stupid.

-Paul

 

[Adam Maass]

lot.

Oh definitely! I had forgotten about this one.

if ( this.equals(that) ) {
...
}
is definitely the right construct.

if ( equals(that) ) {
...
}

is just stupid.

-Paul

I was thinking more like

class Foo {
int a, b, c;
public boolean equals(Object o){
Foo that = (Foo)o;

return this.a == that.a && this.b == that.b && this.c == that.c;
}
}