What is the accepted style for using the `this` keyword in Java?

Question

I come from languages like Python or Javascript (and others that are less object-oriented) and I am trying to improve my working knowledge of Java, which I know only in a superficial way.

Is it considered a bad practice to always prepend this to the current instance attributes? It feels more natural to me to write

...
private String foo;

public void printFoo() {
    System.out.println(this.foo);
}
...

than

...
private String foo;

public void printFoo() {
    System.out.println(foo);
}
...

as it helps me to distinguish instance attributes from local variables.

Of course in a language like Javascript it makes more sense to always use this, since one can have more function nesting, hence local variables coming from larger scopes. In Java, as far as I understand, no nesting like this is possible (except for inner classes), so probably it is not a big issue.

In any case, I would prefer to use this. Would it feel weird and not idiomatic?

Answer 1

In most IDEs, you can simply mouseover the variable if you want to know. In addition, really, if you're working in an instance method, you should really know all the variables involved. If you have too many, or their names clash, then you need to refactor.

It's really quite redundant.

Answer 2

I prefer to use this. It makes it easier to read code in various editors that color local and instance variables in the same way. It also makes it easier to read the code on a printed page during something like a code review. It's also a fairly strong reminder as to the scope of the variable to other developers.

However, there are arguments against this. In modern IDEs, you can find out the scope of a variable by hovering over it or viewing it in a tree-like structure. You can also change the color and/or font face of variables depending on their scope (even in such a way that, when printed, it's evident what the scope of the variable is).

I believe that ChrisF's last sentence is dead on: be consistent in your usage.

Answer 3

One place I consistently use 'this' is setters and or constructors:

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

Other than that, I don't feel it is necessary to add it. When reading the body of a method, parameters and locals are right there - and fairly easy to keep track of (even without the IDE help). Also locals and fields tend to be of different nature (object state vs transient storage or parameter).

If there is any confusion about what's a variable and what's a field, it probably means a method has too many variables/parameters, is too long and too complex, and should be simplified.

If you choose to use 'this' to tag fields, I would recommend to make sure the convention is always strictly followed - it would be really easy to start assuming no 'this' means it's a local and break stuff based on the assumption.

edit: I also end up using this in equals, clone or anything which has a 'that' parameter of the same object type:

public boolean isSame(MyClass that) {
    return this.uuid().equals(that.uuid());
}

Answer 4

Is it considered a bad practice to always prepend this to the current instance attributes?

Yes - by some, no - by others.

I like and use this keyword in my projects in Java and C#. One can argue that IDE will always highlight parameters and fields by different color however we don't always work in IDE - we have to do a lot of merges/diffs/some quick changes in a notepad/check some code snippets in e-mail. It's way easier for me to spot from the first look where instance's state is changed - for example, to review some possible concurrency issues.

Answer 5

It's debatable.

Taking C# as an analogy as it has a very similar syntax and structure to Java we find that C# StyleCop has a default rule that insists you add this, but ReSharper has a default rule that says that the this is redundant (which it is) and can be removed.

So if you are using one tool you'll add them but if you use another you'll remove them. If you are using both tools then you'll have to chose and disable one of the rules.

However, what the rules do mean is that you are consistent in your usage - which is probably the most important thing.

Answer 6

I think that if you need to use this, you either have a method that is too long, or a class that is trying to do too much, or both.

Methods should never be more than a few lines of code long, use one or two local variables, determining what is what becomes easy; even with only the 3 lines context of most diff tools. If your methods are too long and your classes have too many responsabilities (often meaning too many fields), the solution is to split them instead.

I think that "this" just clutters code. Especially with modern IDEs that will color local parameters/local variables/fields differently.

Answer 7

I think you answered your own question with this:

It feels more natural to me to write

... this.foo ...

than

... foo ...

as it helps me to distinguish instance attributes from local variables.

If you are more comfortable using this. while improving your working knowledge with Java, then by all means use the thing (I think it's, in a way, the familiar Python self that you are relating to).

The thing is that, although people will give solid/pertinent arguments about using or not using this., it still sound like a debate, example given:

• it makes the purpose of the variables clear vs. you should rewrite the code if it's not clear what each variable is;
• this. is redundant if you spend your entire day in the IDE vs. I perform code reviews and make diffs on different versions using a comparator with no syntax highlighting;
• not typing this. gains me important milliseconds of productivity vs. I get payed by key pressed and adding this. is like a pay raise :D;
• etc etc

But bottom line is, that at the end of the day, it still resumes to personal preference and work environment.

Answer 8

Normally adding this is unnecessary. I don't think it is bad practice per se, but excessive use of this would probably be considered unusual in most Java code bases that I've seen.

However I find it valuable in a couple of specific situations:

Overriding local parameters - sometimes it is necessary to specify that you want to use an instance variable rather than a parameter / local variable of the same name. This is quite common in constructors, where you want the parameter name to match the internal name of the instance variable it is used to initialise e.g.

class MyObject {
  int value;

  public MyObject(int value) {
    this.value=value;
  }
}

When handling other instances of the same class - I believe it makes the code clearer and more understandable to be explicit which instance of the class you are referring to, e.g.

class MyObject {
  int value;
  ....

  public MyObject add(MyObject other) {
    return new MyObject( this.value + other.value )
  }
}