Is writing "this." before instance variable and methods good or bad style?

Question

I think it's less readable, especially in environments where fields are highlighted differently from local variables. The only time I want to see "this" is when it is required, for example:

this.fieldName = fieldName

When assigning the field.

That said, if you need some way to differentiate fields for some reason, I prefer "this.fieldName" to other conventions, like "m_fieldName" or "_fieldName"

This is a very subjective thing. Microsoft StyleCop has a rule requiring the this. qualifier (though it's C# related). Some people use underscore, some use weird hungarian notations. I personally qualify members with this. even if it's not explicitly required to avoid confusion, because there are cases when it can make one's code a bit more readable.

You may also want to check out this question:
What kind of prefix do you use for member variables?

I'd never seen this style until I joined my current employer. The first time I saw it I thought "this idiot has no idea and Java/OO languages generally are not his strong suit", but it turns out that it's a regularly-occurring affliction here and is mandatory style on a couple of projects, although these projects also use the

if (0 == someValue)
{
    ....
}

approach to doing conditionals, i.e. placing the constant first in the test so that you don't run the risk of writing

if (someValue = 0)

by accident - a common problem for C coders who ignore their compiler warnings. Thing is, in Java the above is simply invalid code and will be chucked out by the compiler, so they're actually making their code less intuitive for no benefit whatsoever.

For me, therefore, far from showing "the author is coding with a dedicated thought process", these things strike me as more likely to come from the kind of person who just sticks to the rules someone else told them once without questioning them or knowing the reasons for the rules in the first place (and therefore where the rules shouldn't apply).

The reasons I've heard mainly boil down to "it's best practice" usually citing Josh Bloch's Effective Java which has a huge influence here. In fact, however, Bloch doesn't even use it where even I think he probably should have to aid readability! Once again, it seems to be more the kind of thing being done by people who are told to do it and don't know why!

Personally, I'm inclined to agree more with what Bruce Eckel says in Thinking in Java (3rd and 4th editions):

---

'Some people will obsessively put this in front of every method call and field reference, arguing that it makes it "clearer and more explicit." Don't do it. There's a reason that we use high-level languages: They do things for us. If you put this in when it's not necessary, you will confuse and annoy everyone who reads your code, since all the rest of the code they've read won't use this everywhere. People expect this to be used only when it is necessary. Following a consistent and straightforward coding style saves time and money.'

---

footnote, p169, Thinking in Java, 4th edition

Quite. Less is more, people.

3 Reasons ( Nomex suit ON)

1) Standardization

2) Readability

3) IDE

1) The biggie Not part of Sun Java code style.

(No need to have any other styles for Java.)

So don't do it ( in Java.)

This is part of the blue collar Java thing: it's always the same everywhere.

2) Readability

If you want this.to have this.this in front of every this.other this.word; do you really this.think it improves this.readability?

If there are too many methods or variable in a class for you to know if it's a member or not... refactor.

You only have member variables and you don't have global variables or functions in Java. ( In other langunages you can have pointers, array overrun, unchecked exceptions and global variables too; enjoy.)

If you want to tell if the method is in your classes parent class or not... remember to put @Override on your declarations and let the compiler tell you if you don't override correctly. super.xxxx() is standard style in Java if you want to call a parent method, otherwise leave it out.

3) IDE Anyone writing code without an IDE that understands the language and gives an outline on the sidebar can do so on their own nickel. Realizing that if it aint' language sensitive, you're trapped in the 1950's. Without a GUI: Trapped in the 50's.

Any decent IDE or editor will tell you where a function/variable is from. Even the original VI (<64kb) will do this with CTags. There is just no excuse for using crappy tools. Good ones are given away for free!.

Sometimes I do like writing classes like this:

class SomeClass{
    int x;
    int y;

    SomeClass(int x, int y){
        this.x = x
        this.y = y
    }
}

This makes it easier to tell what argument is setting what member.

More readable, I think. I do it your way for exactly the same reasons.