Java codestyle: Calling `this`.method()

by Ali Moghnieh

Computer code plays an important role in our every day lives. To some, code would be the equivalent of a spy, it's right in front of them but they're just unaware of its existence. However, in order to maintain order and peace between nations of angry coders, software developers must unite and learn to agree to at least some standards in order to make a certain piece of code, preferably whole projects, readable.

Depending on the computer language, different code styles are used to maintain an understanding between multiple parties when reading code. This, however, is not required of one coder but failure to follow a consistent style might lead to their isolation from developers, especially if they're picky, which is something very common in the code-writing community.

I wanted to write this blog based on a recent experience I had with a project's codestyle. The codestyle required that all non-static method calls require this to prefix the method call, so instead of:

myReplacingMethod("String");

One would write:

this.myReplacingMethod("String");

I personally think it is flawed, but I'm more interested in what the public has to say about it.

I tried looking around but I've found no one to follow this code style. The argument that was made for this codestyle is that it further expresses the method call, by stating that it does in fact belong to this class, its superclass, or one of its superinterfaces. Now in some languages this might be neat and definitely expressive, but with respect, this is Java.

It has been argued that your mind will immediately scan this and ignore it, however true it may be, it will still cause the line of code to grow longer:

this.doUpdate(this.format(data));

As opposed to:

doUpdate(format(data));

The longer the line of code the more the reader will have to unnecessarily read, eventually having to go through the effort of moving their eyes to focus on reading on an average size text viewer like GitHub's code viewer.

It has also been argued that the explicitness is an advantage when dealing with static method imports. :fearful: My immediate response to this is that you don't use static method imports unless the method is being used more than enough times that it would help if the owning class name was removed. For example, a StringUtils class that calls String.format() frequently enough that it would be convenient to read and write code by statically importing and removing the owning class name. format() as opposed to String.format();.

I'm all for readability outside of IDEs, but I think that using this to further express the location of the method is just extra clutter as it is always immediately obvious whether the method is statically imported or residing in the class' hierarchy.

With that said, this has nothing to do with fields referencing, fields and methods are two very different things and should not be compared. Always use this when referring to class fields to make it both readable inside and outside IDEs.

TL;DR :-1: this.methodName() in Java as it adds clutter, but always use it with fields.