Why Java uses convention of this.member?

Question

I quite often see the following naming convention used in java code.

class SomeClass {
    private final String name;

    public SomeClass(final String name) {
        this.name = name;
    }
}

This seems a little odd to me. First off if you happen to misspell the variable in the method signature it will still compile...

class SomeClass {
    private final String name;

    public SomeClass(final String nane) {
        this.name = name;
    }
}

Compiles fine. Possibly flags nane as unused variable but the assignment (which just becomes a self assignment) silently compiles.

I find myself wanting to use 'm' for member variables as such...

class SomeClass {
    private final String mName;

    public SomeClass(final String name) {
        mName = name;
    }
}

It is shorter than the .this variant and catches the odd misspelling error shown previously.

However a colleague of mine gave me all kinds of flack when I brought this up as a convention on our new project stating that "in java we don't do that.".

Just curious as to why?

Answer 1

Modern IDEs such as Eclipse can automatically generate getters and setters for you so this way troubles can be avoided.

Answer 2

Personally I don't like using prefixes - it makes the code harder to read, IMO. I believe different people read in different ways - I end up reading "aloud in my head" and the prefixes interrupt this process. Obviously you can get used to it, but I'd rather not have to.

However, it would be a mistake to claim that no-one used prefixes like this. I've worked at various different companies using Java - some used prefixes, some didn't.

I'd also point out that most IDEs will give you a warning about a no-op assignment in your typo example. For example, in Eclipse I get:

The assignment to variable name has no effect

If you regularly ignore warnings, I'd say you have bigger problems :)

Answer 3

I'd rather use this only in the few places where needed to clear the ambiguity, than drag with me the prefixes everywhere in the code.

Answer 4

In the first example, the this qualifier is necessary to explicitly reference the instance member name as opposed to the local variable (method parameter) name.

You're right when you mention about the possibility of misspellings of the parameter name, and this has been the source of some frustrating bugs. In the past, I've also used a prefix naming convention for fields, but as java more and more relies on reflection, this does introduce some level of pain, so lately I've moved away from it.

The liklihood of bugs due to misspelling can be reduced by using unit tests, and also by using an IDE that analyses the code prior to checking in and flags these kids of errors for you.

Answer 5

Using specific prefixes for member variables is a kind of Hungarian notation - the technical, bad kind. The information (what is and is not a member variable) is already in the code, no need to duplicate it.

As you've noted, a good IDE will warn you about the unused variable (and probably allow you to turn that warning into an error). The syntax highlighting will also distinguish between local and member variables. Why come up with ugly code conventions to do the IDE's job of making one very specific kind of programmer mistake less likely?

Answer 6

I actually had a lecture where a prof of mine gave us the following java class in an assignment:

public class Person {
    private String name;
    private int age;

    public Foo(String __name, int __age) {
        name = __name;
        age = __age;
    }

    public String sayHello() {
        return "Hello, my name is " + name + " and I am " + age + " years old";
    }
}

I referred to the Java Coding Conventions and kindly asked him if I can refactor his code. Basically this is for writing beautyful constructors and setters. And of course for all other cases for which I would otherwise need to rename method parameters to underunder + parameter name or even better p + parameter name as I have seen so often.

Answer 7

It looks odd to me that your question make an assumption that

Java uses the convention of this.member

By no mean is this true, because different people have different conventions. In my code there are a lot of this.member, but that's only because my IDE (netbeans) generates that, and I don't care that much to rewrite.

Answer 8

this.member is not a convention but it's necessary, for example, when you must explicitly refer to an instance variable that have the same name of a local variable into a method.

In other not mandatory cases you can omit it, because it's implicit, and choose what convention you want.