Geek Answers Handbook

Why does Java use this user's convention?

I pretty often see the following naming convention used in Java code.

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

It seems a little strange to me. First of all, if you accidentally miss a variable in the method signature, it will still compile ...

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

Compiles in order. The nane flag may be used as an unused variable, but the assignment (which just becomes an independent assignment) imperceptibly compiles.

I believe I want 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 this option, and detects a previously odd spelling error.

However, my colleague gave me all kinds of flash when I presented this as an agreement on our new project, stating that "we do not do this in java."

Just curious why?

+4
source share
8 answers

Personally, I don’t like using prefixes - it makes the code harder to read, IMO. I believe that different people read differently - I finish reading “out loud in the head,” and prefixes interrupt this process. Obviously, you can get used to it, but I would not want that.

However, it would be a mistake to claim that no one used prefixes like this. I worked in different companies using Java - some used prefixes, others not.

I would also note that most IDEs will give you a warning about the no-op assignment in the typing example. For example, in Eclipse I get:

 The assignment to variable name has no effect

If you regularly ignore warnings, I would say that you have big problems :)

+15
source

I would prefer to use this only in those few places where it is necessary to clear the ambiguity, than to drag prefixes with me everywhere in the code.

+9
source

Using specific prefixes for member variables is a kind of Hungarian notation - technical, bad. Information (which is and is not a member variable) is already in the code, you do not need to duplicate it.

As you already noted, a good IDE will warn you about an unused variable (and will probably allow you to turn this warning into an error message). Syntax highlighting will also distinguish between local and member variables. Why come up with ugly code conventions to do an IDE job to make one particular programmer’s mistake less likely?

+5
source

Modern IDEs like Eclipse can automatically generate getters and setters for you, so you can avoid problems this way.

+2
source

In the first example, the this qualifier must explicitly refer to a member of the name instance, and not to the local variable (method parameter) name .

You are right when you mention the possibility of erroneous parameter name names, and this has become the source of some disappointing errors. I used to use a naming convention for the prefix for fields, but since java relies more and more on reflection, this leads to some level of pain, so lately I moved away from it.

Spelling errors can be reduced by using unit tests, as well as by the IDE, which analyzes the code before checking and puts these kids errors for you.

+1
source

It seems strange to me that your question suggests that

Java uses this user convention

This is by no means the case, because different people have different agreements. There is a lot of this in my code, but this is only because my IDE (netbeans) generates this, and I don't care to rewrite.

+1
source

this.member not conditional, but it is necessary, for example, when you must explicitly reference an instance variable with the same local variable name in the method.

In other optional cases, you can omit it because it is implicit and choose which agreement you want.

+1
source

Actually, I had a lecture in which my pro gave us the following java class in the task:

 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 mentioned Java Coding Conventions and kindly asked him if I could refactor his code. This is mainly intended for writing beautiful designers and setters. And, of course, for all other cases for which otherwise I would need to rename the method parameters to underunder + the parameter name or even the best parameter name p +, as I saw so often.

0
source

More articles:


All Articles