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?

  • I'm pretty sure you can configure Eclipse to not use this.. If you want to. Feb 19, 2012 at 6:35
  • 5
    In this case not using this. would cause the code to not work as intended.
    – user7519
    Feb 19, 2012 at 8:34
  • 2
    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, 2012 at 10:47
  • Semi-offtopic, but: the best way to write a setter is to not write a setter. Immutable data structures significantly simplify reasoning about data flows in a program, often leading to fewer bugs.
    – 9000
    Mar 16, 2017 at 15:43

11 Answers 11


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.


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.


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.


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.

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.


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.


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


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.)

  • 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, 2012 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, 2012 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 = obj.name; rather than String name = obj.getName(); or obj.name = "NewName"; rather than obj.setName("NewName");.
    – Mark Booth
    Feb 21, 2012 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, 2012 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, 2012 at 17:08

It doesn't really matter. Nobody will ever look at the source code for your setter if it is trivial like that, so nobody cares which method you are using.


I would argue that one should always prefer

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

in Java code. It seems to be the convention most Java developers follow. At least the majority of Java code i have seen in the past 15 years or so is written like this. That's code from various codebases, companies, projects, code snippets and examples. Not following conventions is in itself not a bad thing, but usually is a cause of friction (in this case you will slightly offend a trained Java brain's pattern recognition), and should be justified with a significant gain, which I fail to see here.

Another point would be that prefixing variables/parameters with semantic context (Hungarian notation, in/out for in/out parameters, etc.) is widely discouraged throughout the programming community, nowadays. These prefixes have a tendency to lie after some refactorings. Setters are simple enough, that it's safe the say that the parameter will always be an in-parameter (otherwise it would not be a setter anymore, would it). You should have the same convention for names throughout your codebase, though, including setters.

  • this seems to merely repeat points already made and explained in at least 3 prior answers that were posted 5 years ago
    – gnat
    Mar 17, 2017 at 11:13
  • Seems I overlooked them them. What I did see was one "There is no real difference" post after the other. Besides, are repeated points a negative thing? I do not see all the other, seemingly same, answers being downvoted. Mar 17, 2017 at 11:38

Something that wasn't mentioned in the other answers, the common idiom

this.unitCost = unitCost;

will be a hard to spot bug if you forget the this just once in a code base.

Declaring the parameter as final might look like a safeguard but in practice most programmers let the IDE do that automatically and of course it won't do that once you have the line unitCost = unitCost; in your code.

So I see a good reason to use the first idiom, i.e. make the name of the parameter and field different:

unitCost = pUnitCost; //p for parameter
  • 1
    Hungarian notation went the way of the dodo with code completion.
    – jwenting
    Mar 16, 2017 at 11:16
  • @jwenting What is your suggestion to prevent the bug that happens in case you forget to write this.?
    – Roland
    Mar 16, 2017 at 11:24
  • be careful writing it, good unit tests, and many editors and compilers will issue warnings if not always errors when you do it wrong.
    – jwenting
    Mar 16, 2017 at 11:28
  • 1
    @Roland: Objective-C solves this by using the convention that the instance variable always starts with an underscore. So you are free in your implementation to use the instance variable, or to use the getter / setter, but it's always clear which one it is. Actually, in Objective-C this.unitCost = xxx would call the setter, so using this in the setter causes infinite recursion. Well, you don't need unit tests for this, because it's a bug that is impossible to not notice.
    – gnasher729
    Mar 16, 2017 at 11:53
  • @jwenting No warning or error from IntelliJ IDEA ultimate 2016.1
    – Roland
    Mar 16, 2017 at 12:12

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