Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am am trying to learn JAVA on my own. In one book I am reading the author says there is no convention for writing a correct setter. His example would go something like this:

public void setUnitCost(double inUnitCost) {
     unitCost = inUnitCost;

However, when using Eclipse, and tell it to create getters and setters it does this:

public void setUnitCost (double unitCost){
     this.unitCost = unitCost;

My question is which way is better? Does it make a difference in the programming world? What exactly is the difference between the two?

share|improve this question
I'm pretty sure you can configure Eclipse to not use this.. If you want to. – FrustratedWithFormsDesigner Feb 19 '12 at 6:35
In this case not using this. would cause the code to not work as intended. – Jarrod Roberson Feb 19 '12 at 8:34
The name "inUnitCost" seems to me like legacy. In procedural times you had no return values but in and out parameters which had to carry "in" or "out" as a keyword (see PL/SQL for example). The author must have been influenced by such languages. In Java, there's no reason anymore to name something "in<Name>". – Falcon Feb 19 '12 at 10:47

There is no significant difference. They both produce the same result.

I personally prefer the Eclipse version, as I find:

  • It is more elegant for the name in the parameter list to be the same as the field used internally in the object.
  • Having the unitCost parameter name looks and works better in code completion than inUnitCost or similar (since you are also likely to use the name unitCost in calling code).
  • It is nice to be explicit about the fact that you are setting a field with the this. My code pattern recognition here immediately says "ah... this line is setting a field in the current object".

But that's ultimately just a style choice.

share|improve this answer

There is no significant difference between the two.

The difference (aside from the whitespace) is that one explicitly uses this to set the new value. As far as I know, there isn't any advantage or disadvantage to doing that.

share|improve this answer

It's just a style choice. Some programmers get annoyed by having to come up with stupid names like inUnitCost or newUnitCost for the function parameters. Some get annoyed by having to notice the unitCost symbol from the function parameter overrides the unitCost symbol for the object member. You should stick with whatever consensus you reach with your colleagues.

share|improve this answer

The first example is likely to be seen in some circles as poor convention as it makes the input value look as though it is in Hungarian Notation.

Many code completion and formatting tools will encourage you to use this in order to be explicit in your use of variables. I tend to agree with this, as it makes it very clear at a glance whether the variable is local or belongs to the class. Of course, if you are keeping all of your methods nice and short on the order of only a few lines, and the method parameter lists are likewise quite short, then it may not necessarily be an issue for you. Personally I still prefer to see this liberally sprinkled around the code, as this makes variables stand out distinctly due to the syntax highlighting that most modern IDE's provide you with, and the less I have to actually look into the code too deeply, the less distracted I get when jumping around the code while trying to solve complex logic problems in my head.

With that said, the compiler won't care a jot which way you've written your setters. Your colleagues on the other hand may have differing opinions, so it is up to you all to decide which approach you might wish to enshrine in a coding standard.

share|improve this answer

As an automatic code generation tool, the Eclipse generator is not necessarily beholden to the same rules which govern what's worth the effort for human programmers. Don't forget that.

The two are entirely equivalent in this case, however.

share|improve this answer

The most modern idiomatic code would be:

public void setUnitCost(final double unitCost)
     this.unitCost = unitCost;
  1. marking the argument final is important; using JSR305 @Nonnullable/@Nullable when working with object references is even better for self documenting the intentions of the code.
  2. this. is self documenting that you are setting the current instance and not some variable in a super class, which should idiomatically use super.
share|improve this answer

There's no difference between them. as long as it fulfills it task in an efficient way it is fine. I do write my Setters(sometimes) this way

public void setFoo(String fooName){
  this.fooName = fooName;

The reason I used this is that I lack the idea of proper naming of variables. but nonetheless you can write a setter what suits you.

But I prefer the first setter, since there might errors occur on the second one

share|improve this answer

This might rub a few people the wrong way, but I'd say do not write (or generate) code that merely gets or sets a variable, as it leads to clutter and more lines of code to read / scan to understand what your class does. This clutter can take attention away from code that does actually have specific implementation details other than merely getting or setting a variable.

The Lombok library provides @Getter & @Setter annotations to alleviate you from having to write (and others to read) 'dumb' getter and setter methods. At compile time Lombok will generate these methods for you, and their IDE integration means you won't notice the difference when developing.

(There is even a de-lombok option to generate source code with the appropriate getters and setters in place, without any dependency on Lombok, but I wouldn't recommend it unless you have to meet some really weird requirements.)

share|improve this answer
Great answer, ever since moving from C# to Java, I've missed C# properties. Using Lombok won't be quite as nice as having properties as part of the language, but it would sure reduce the need to write lots of boilerplate getter/setter code. – Mark Booth Feb 21 '12 at 15:44
Have a look at the other Lombok annotations to see what more boilerplate code you can remove using it. \@Data for instance provides \@Getters and \@Setters for all fields, and generates equals, hashcode & toString methods all at once. – Tim Feb 21 '12 at 15:55
Yup, those are nice too, but still the @Getter & @Setter annotations through Lombok aren't as nice as real C# properties, where you can write var name =; rather than String name = obj.getName(); or = "NewName"; rather than obj.setName("NewName");. – Mark Booth Feb 21 '12 at 16:09
I only have 15 minutes experience with C#, so I might be missing something, but how's that different from a public String name ? I'm not trying bash C#, I just honestly want to understand.. – Tim Feb 21 '12 at 16:44
It would probably be better to take this to chat but essentially, a property is syntactic sugar for getter/setter functions that looks like assignments when used, i.e. they have the power of a full function behind them. The biggest advantage is that if you define a property as part of an interface, then any implementation can initially define an auto-property & then turn it into a real property later (maybe to add validation). If you'd defined it as a public field then you couldn't replace it with a property later without changing the Interface and destroying backward compatibility. – Mark Booth Feb 21 '12 at 17:08

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.