Naming convention for getters/setters in Java

Question

if I have the following private member:

private int xIndex;

How should I name my getter/setter:

getXindex()
setXindex(int value)

or

getxIndex()
setxIndex(int value)

EDIT: or

getXIndex()
setXIndex(int value);

?

Name your field "indexX" or whatever else, your problem is solved... don't overcomplicate things - even if `setxIndex` is the correct way for Beans, having method named `setxIndex` increases the *WTF factor* of the code without giving you anything in return. If your car driver is sick, don't think how to fix the car, replace the driver. — , Nov 09 '14 at 08:48

score 38 · Accepted Answer · edited Oct 09 '17 at 07:45

38

The correct answer is

getxIndex()
setxIndex(int value)

if you want them to be used as properties according to section 8.8: Capitalization of inferred names of the JavaBeans API specification (e.g. access them via ${object.xIndex} in a JSP.

edited Oct 09 '17 at 07:45

Steve Chambers

31,993
15
129
173

answered Apr 22 '13 at 11:36

Thomas Einwaller

8,371
4
35
51

7

I wrote a blog post about it: http://dertompson.com/2013/04/29/java-bean-getterssetters/ – Thomas Einwaller Dec 13 '13 at 07:56
2

I don't think this is correct. Section 8.8 refers to capitalization of a property name inferred from the method name. This question is asking about the reverse process of naming the method based on the property name. The javadoc for Inspector.decapitalize() states that it is a "method to take a string and convert it to normal Java **variable name**", not method name as in this case. – Mirza Dobric Apr 04 '14 at 23:31
Trust me, it is correct. In the meanwhile even all the IDEs are generating these getters and setters correct (IntelliJ, Eclipse, Netbeans, ...) – Thomas Einwaller Apr 23 '14 at 14:39
The specification states `we check if the first two characters of the name are both upper case and if so leave it alone.` In the case of `xIndex`, only the first one is. How am I misreading this (I assume I am)? – Sotirios Delimanolis Apr 29 '14 at 14:53
1

@SotiriosDelimanolis the sentence from the spec you quote takes about _upper_ case. Hence, it shouldn't apply here. – Marcel Stör Apr 21 '15 at 19:17
1

you have to think “the other way around”: If you would make the getter getXIndex the decapitalize method would look at XIndex and decide there is nothing to decapitalize – so it returns XIndex and this property does not exist. – Thomas Einwaller Apr 22 '15 at 10:39
1

actually this is a wrong answer .. the correct answer is getXIndex(); "The method name must have a prefix of set/get/is, followed by the first letter of the property in uppercase, followed by the rest of the property name." JAVA SE 8 OCA – Mahmoud Turki Oct 19 '19 at 22:45

Love · Answer 2 · 2021-03-28T09:31:20.287

In accordance with JavaBeans API specification from 1997 it should be as Thomas Einwaller describes:

// According to JavaBeans API specification
public int getxIndex() { return xIndex; }
public void setxIndex(int xIndex) { this.xIndex = xIndex; }

This is unfortunate, getx and setx are not words. In the rare case when this would form a word or acronym it would be disinformative, eg the method setiMessage most likely has nothing to do with SETI. Using the only valid measurement of code quality (WTFs per minute), I assess that this is bad code.

If we modify this to follow the convention for naming a method it would be:

// According to Java naming convention
public int getXIndex() { return xIndex; }
public void setXIndex(int xIndex) { this.xIndex = xIndex; }

Why does the JavaBeans specification violate the convention? It all comes down to this sentence of the JavaBeans specification:

However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone.

Exactly what kind of use of all upper-case names this refers to is unclear to me. Field names should, according to convention, be camel cased. It seems to me that we generate unconventional method names in order to support unconventional field names as decided by a 20+ year old document.

It should also be noted that even though it seems to be an overwhelming support for the JavaBeans specification in tools, it is not exclusively used. Eg. Kotlin will not recognize xIndex as a property in the above example. Reversely, the Kotlin property var xIndex = 0 will result in the Java methods getXIndex and setXIndex. This seems to be a bug according to the JetBrains support, but I fail to see how they can fix that without making a breaking change.

Some tools that does support the JavaBeans specification has not always done so, eg Jackson and Swagger Code Generator have been patched to conform to it. Even though IntelliJ generate accessors according to the JavaBeans specification, the example in the documentation differs from it. Probably because people don't know about the standard and naturally prefers the normal method naming convention.

So when should we follow the JavaBeans specification? When property names should be inferred by accessors by tools that rely on this standard, then we might want to use it. For instance, Jackson will rely on the property xIndex being accessed through getxIndex and setxIndex methods unless we use annotations.

When should we avoid this standard? Per my recommendation: When the code should be read and understood by humans. Because to not use proper camel casing when naming methods is disinformative.

If I would have it my way, we would use normal naming conventions, ie getXIndex and setXIndex. But, given the state of things, the best solution I see is suggested by @vaxquis:

Name your field "indexX" or whatever else, your problem is solved... don't overcomplicate things - even if setxIndex is the correct way for Beans, having method named setxIndex increases the WTF factor of the code without giving you anything in return.

Any comments regarding the JavaBeans specification should, according the specification itself, be sent to java-beans@java.sun.com.

I'd use `setXIndex` and add a BeanInfo class to deal with this unintuitive corner case of the spec, if `setIndexX` isn't possible. — toolforger, Feb 04 '21 at 12:58

score 5 · Answer 3 · edited Aug 07 '15 at 05:17

5

Should be:

getXIndex()
setXIndex(final int xIndex)

edited Aug 07 '15 at 05:17

stites

3,913
5
28
43

answered Jun 01 '10 at 08:03

Samuel Yung

706
6
12

2

If this is the right answer, why IDEs (tested Intellij, read Eclipse too) generate something else? They generate getxIndex() and setxIndex(). Can someone clarify? – kctang Nov 07 '12 at 15:04
8

not correct, those getters are not conform with the Java Bean naming conventions – Thomas Einwaller Apr 22 '13 at 11:34
4

This answer is not correct, the one from @ThomasEinwaller is, because this is clearly specified, and not something we need to argue about :) – Martin C. Dec 16 '13 at 08:10

score 1 · Answer 4 · answered Jun 01 '10 at 08:55

1

Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.

answered Jun 01 '10 at 08:55

ayush

13,272
9
49
95

score 0 · Answer 5 · answered Feb 23 '15 at 14:59

0

You should use Introspector.decapitalize from package java.beans and you have no problem beacause it is compliant with java rules.

answered Feb 23 '15 at 14:59

Hervé Darritchon

279
1
14

score 0 · Answer 6 · edited May 22 '16 at 18:52

0

Eclipse ide automatically generates setters and getters as:

getxIndex()
setxIndex(int value)

Which is according to the java beans API specification.

edited May 22 '16 at 18:52

Skatox

3,919
10
39
42

answered May 22 '16 at 18:34

Bipin Thakur

139
5

score -2 · Answer 7 · answered Jun 01 '10 at 08:09

-2

I think getXindex() is the best way. The getter should start with 'get', followed by the member name, with its first letter capitalized. Also the latest conventions I heard of, say that we should avoid multiple capital letters one after another. For example getHTMLtooltip is wrong. it should be getHtmlTooltip instead. Also you should try to make all your members final and there should not be a need of setters, since the class will be immutable ;)

answered Jun 01 '10 at 08:09

m_pGladiator

8,010
7
41
60

@m_pGladiator: re immutable: while this is obviously desirable, not all classes can be made immutable. but of course: setters should only be present if needed. @Simon: the main reason is thread safety. if a class is immutable, no problems of concurrent modification through separate threads can ever arise – Sean Patrick Floyd Jun 01 '10 at 08:23
Sorry, I didn't read the "javabeans" tag. The beans architecture presumes getters and setters and does not favor immutability – m_pGladiator Jun 01 '10 at 11:30
Downvote, as the case mentioned in the question is specified in the spec, see other answers. – Martin C. Dec 16 '13 at 08:15

Naming convention for getters/setters in Java

7 Answers7

Linked

Related