Correct format for setters

Question

I have been developing Java as a hobby for the last 4 years and I am interested in the convention for Java Bean setters.

If I use Eclipse to generate my Setters I get:

private String var;

public void setVar(String var){
 this.var = var;
}

Now I understand how that works but to me (being a developer of old) having two variables with the same name but identifying different objects is confusing. I find if you misspell the parameter variable, e.g bar it still compiles but doesn't work;

My inclination is to use:

private String var;

public void setVar(String varp){
 var = varp;
}

Can anyone explain are there any efficiencies or advantages of either method.

loog [here](https://stackoverflow.com/questions/55391113/how-setter-works-inside-spring-framework-2) I think it would be clear — Dred, Apr 05 '19 at 12:42
@Dred I don't see how this is related to the question. @Mikerb except what you said about misspelling, I see no real advantage than clarity, but I personnally would let the `this` in your version. Being an old school coder too, i always had problems with same name vars, so I totally understand (BASIC someone?) — Kaddath, Apr 05 '19 at 12:46
There is one thing which is *highly recommended*: Use what you like, but be consistent all over the code/project. — deHaar, Apr 05 '19 at 12:47
This is opinion-based. The first one means I don't have to think of random prefixes, suffixes, or other alternative names for the parameter. — Michael, Apr 05 '19 at 12:48
I already voted, but this is a duplicate of https://stackoverflow.com/questions/991757/best-practice-for-parameter-naming-in-java-constructors-and-simple-setters. Can someone dupe-hammer? :) — Michael, Apr 05 '19 at 12:50
Thanks @Michael I did do a search but obviously did not get the right words to catch this one. I am happy for my question to be classed as a duplicate. — Mikerb, Apr 05 '19 at 13:10
@Mikerb That's fine. It's good to have "signpost" questions pointing to the main one. If you struggled to find it then others will too. — Michael, Apr 05 '19 at 13:11
Possible duplicate of [Best practice for parameter naming in Java constructors and simple setters](https://stackoverflow.com/questions/991757/best-practice-for-parameter-naming-in-java-constructors-and-simple-setters) — TylerH, Apr 05 '19 at 13:21
That's strange, I voted to close as a duplicate and as a result it closed as opinion-based. I'm new to close votes, if someone thinks it should be corrected and can, just do it — Kaddath, Apr 05 '19 at 13:24
@Kaddath Questions get closed with the reason a majority voted for. Because there were 3 POB votes and only 2 duplicate votes, the reason given for closure was POB. There are some exceptions where three different reasons are given (2, 2, and 1 vote each). In those cases multiple reasons can be shown, but a duplicate closure has to be a majority reason to be shown because duplicate closures are a special case. — TylerH, Apr 05 '19 at 13:39
When you have many setters [this](https://stackoverflow.com/a/55536868/3992939) style may be handy. — c0der, Apr 05 '19 at 13:49
Thanks for all of the opinions. My initial question was looking for fact. i.e 'Any efficiencies or advantages'. The answer is 'None'. The rest of the input was therefore opinion. I accepted @t-j-crowder answer as it was the clearest. — Mikerb, Apr 06 '19 at 09:40

score 1 · Accepted Answer · answered Apr 05 '19 at 12:44

Can anyone explain are there any efficiencies or advantages of either method.

It's purely a matter of style. There are two aspects of style here, slightly interconnected:

Having an instance variable (field) and parameter with the same name.
Leaving off this. when accessing an instance variable (or method).

Using the same name forces you to use this., but using different names doesn't mean you can't use this., which is why they're separate but interconnected style issues.

All of these are valid choices (assume the instance variable declaration), and in terms of what the compiler does, it makes no difference which you use:

// 1
public void setVar(String var) {
    this.var = var;
}

// 2
public void setVar(String varp) {
    var = varp;
}

// 3
public void setVar(String varp) {
    this.var = varp;
}

It makes a difference to maintainability and such, but that comes down to style, which is up to you and/or the style guide of the project you're working on.

(IMHO, it's objectively clearer to use `this.` when referring to instance variables and methods, and clarity is good. But opinions vary on whether the clarity is worth the repeated `this.`s. I think it is, and some agree with me. Others don't.) — T.J. Crowder, Apr 05 '19 at 12:51

score 0 · Answer 2 · answered Apr 05 '19 at 12:45

There are no advantages on any of the methods. The code compiled is equal.

To prevent accidentially set your parameter var instead of this.var, it's good habit to add final to (all) parameters.

public void setVar(final String var) { 
    this.var = var; 
    // var = var; // fails, because var cannot be set again.

score 0 · Answer 3 · answered Apr 05 '19 at 13:09

Repeating the variable name is understandable. to have more clear way of getting and setting

public class test{
   private String name;

   public void setVar(String name){
     name = name;
   }
}

When you try to set the value, and have the expression as mentioned above.

test t1 = new test();
t1.setVar("myValue");

What the code wants to do is

 t1.name = myValue;

If there are multiple objects for class test being created and manipulated, the assignment will get cluttered, as the private variable is been accessed and assigned value.

What you want to do, is to make sure that the variable instance that your object holds, is getting addressed only. Thats why you add

public class test{
   private String name;

   public void setVar(String name){
     this.name = name;
   }
}

Now, every instance of class test t1 ,t2 .. etc will have the manipulation done for their objects only. The naming of the variable passed is kept the same to the variable we want to assign value to, as purely maintainability.

Correct format for setters

3 Answers3