Today I had a discussion with a co-worker about the naming of final fields in Java classes.
In his opionion final fields should also be considered constants since their values won’t change after the creation of the instance.
This would lead to the following naming convention for final fields:
public class Foo {
private static final String BLA_BLA = "bla";
private final String BAR_BATZ;
...
}
In my opinion only static final fields should be considered constants while fields which are only final should follow the usual camelCase naming convention.
public class Foo {
private static final String BLA = "bla";
private final String barBatz;
...
}
Now I’m a bit uncertain since he is a far more experienced programmer than I am, so I’m looking for additional input on this.
7
Sun (and now Oracle) maintained a document titled Code Conventions for the Java Programming Language. The last update to this was in ’99, but the essence of the style guide line lives on.
Chapter 9 covers naming conventions.
For an identifier type of ‘constants’:
The names of variables declared class constants and of ANSI constants should be all uppercase with words separated by underscores (“_”). (ANSI constants should be avoided, for ease of debugging.)
The examples given:
static final int MIN_WIDTH = 4;
static final int MAX_WIDTH = 999;
static final int GET_THE_CPU = 1;
In a more recent document – its slipped in there. From Variables (The Java Tutorials > Learning the Java Language > Language Basics:
If the name you choose consists of only one word, spell that word in all lowercase letters. If it consists of more than one word, capitalize the first letter of each subsequent word. The names
gearRatioandcurrentGearare prime examples of this convention. If your variable stores a constant value, such asstatic final int NUM_GEARS = 6, the convention changes slightly, capitalizing every letter and separating subsequent words with the underscore character. By convention, the underscore character is never used elsewhere.
Many static analyzers for Java seek to enforce this. For example checkstyle enforces:
Checks that constant names conform to a format specified by the format property. A constant is a static and final field or an interface/annotation field, except
serialVersionUIDandserialPersistentFields. The format is a regular expression and defaults to^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$.
This really boils down to the conventions of the community writing the code… and ideally keeping it the same.
The examples above are given as static final ones which are likely derived from the C conventions for #define – which like C, are replaced in the code during compilation rather than at runtime.
The question that then should be asked is “is this behaving like a constant? or is it behaving like a write once field?” – and then following the conventions accordingly. The litmus test for such a question would be “If you were to serialize the object, would you include the final field?” If the answer is that it is a constant then treat it as such (and don’t serialize it). On the other hand, if it is part of the state of the object that would need to be serialized, then it isn’t a constant.
Whatever the case, it is important to stick with the code style however right or wrong it is. Worse problems erupt from inconsistent conventions within a project than merely something that offends the eye. Consider getting some static analysis tools and configure them to maintain consistency.
6
BAR_BATZ isn’t a constant in this example. The constructors of Foo can set it to different values at the object level. For example
public class Foo {
private final String BAR_BATZ;
Foo() {
BAR_BATZ = "ascending";
}
Foo(String barBatz) {
BAR_BATZ = barBatz;
}
}