Java final static naming

Java naming convention for static final variables

That’s still a constant. See the JLS for more information regarding the naming convention for constants. But in reality, it’s all a matter of preference.

The names of constants in interface types should be, and final variables of class types may conventionally be, a sequence of one or more words, acronyms, or abbreviations, all uppercase, with components separated by underscore «_» characters. Constant names should be descriptive and not unnecessarily abbreviated. Conventionally they may be any appropriate part of speech. Examples of names for constants include MIN_VALUE , MAX_VALUE , MIN_RADIX , and MAX_RADIX of the class Character .

A group of constants that represent alternative values of a set, or, less frequently, masking bits in an integer value, are sometimes usefully specified with a common acronym as a name prefix, as in:

• Constant names normally have no lowercase letters, so they will not normally obscure names of packages or types, nor will they normally shadow fields, whose names typically contain at least one lowercase letter.
• Constant names cannot obscure method names, because they are distinguished syntactically.

Solution 2

The dialog on this seems to be the antithesis of the conversation on naming interface and abstract classes. I find this alarming, and think that the decision runs much deeper than simply choosing one naming convention and using it always with static final .

Abstract and Interface

When naming interfaces and abstract classes, the accepted convention has evolved into not prefixing or suffixing your abstract class or interface with any identifying information that would indicate it is anything other than a class.

public interface Reader <> public abstract class FileReader implements Reader <> public class XmlFileReader extends FileReader <> 

The developer is said not to need to know that the above classes are abstract or an interface .

Static Final

My personal preference and belief is that we should follow similar logic when referring to static final variables. Instead, we evaluate its usage when determining how to name it. It seems the all uppercase argument is something that has been somewhat blindly adopted from the C and C++ languages. In my estimation, that is not justification to continue the tradition in Java.

Question of Intention

We should ask ourselves what is the function of static final in our own context. Here are three examples of how static final may be used in different contexts:

public class ChatMessage < //Used like a private variable private static final Logger logger = LoggerFactory.getLogger(XmlFileReader.class); //Used like an Enum public class Error < public static final int Success = 0; public static final int TooLong = 1; public static final int IllegalCharacters = 2; >//Used to define some static, constant, publicly visible property public static final int MAX_SIZE = Integer.MAX_VALUE; > 

Could you use all uppercase in all three scenarios? Absolutely, but I think it can be argued that it would detract from the purpose of each. So, let’s examine each case individually.

Purpose: Private Variable

In the case of the Logger example above, the logger is declared as private, and will only be used within the class, or possibly an inner class. Even if it were declared at protected or package visibility, its usage is the same:

public void send(final String message) < logger.info("Sending the following message: '" + message + "'."); //Send the message >

Here, we don’t care that logger is a static final member variable. It could simply be a final instance variable. We don’t know. We don’t need to know. All we need to know is that we are logging the message to the logger that the class instance has provided.

You wouldn’t name it LOGGER in this scenario, so why should you name it all uppercase if it was static final ? Its context, or intention, is the same in both circumstances.

Note: I reversed my position on package visibility because it is more like a form of public access, restricted to package level.

Purpose: Enum

Now you might say, why are you using static final integers as an enum ? That is a discussion that is still evolving and I’d even say semi-controversial, so I’ll try not to derail this discussion for long by venturing into it. However, it would be suggested that you could implement the following accepted enum pattern:

public enum Error < Success(0), TooLong(1), IllegalCharacters(2); private final int value; private Error(final int value) < this.value = value; >public int value() < return value; >public static Error fromValue(final int value) < switch (value) < case 0: return Error.Success; case 1: return Error.TooLong; case 2: return Error.IllegalCharacters; default: throw new IllegalArgumentException("Unknown Error value."); >> > 

There are variations of the above that achieve the same purpose of allowing explicit conversion of an enum->int and int->enum . In the scope of streaming this information over a network, native Java serialization is simply too verbose. A simple int , short , or byte could save tremendous bandwidth. I could delve into a long winded compare and contrast about the pros and cons of enum vs static final int involving type safety, readability, maintainability, etc.; fortunately, that lies outside the scope of this discussion.

The bottom line is this, sometimes static final int will be used as an enum style structure.

If you can bring yourself to accept that the above statement is true, we can follow that up with a discussion of style. When declaring an enum , the accepted style says that we don’t do the following:

Instead, we do the following:

If your static final block of integers serves as a loose enum , then why should you use a different naming convention for it? Its context, or intention, is the same in both circumstances.

Purpose: Static, Constant, Public Property

This usage case is perhaps the most cloudy and debatable of all. The static constant size usage example is where this is most often encountered. Java removes the need for sizeof() , but there are times when it is important to know how many bytes a data structure will occupy.

For example, consider you are writing or reading a list of data structures to a binary file, and the format of that binary file requires that the total size of the data chunk be inserted before the actual data. This is common so that a reader knows when the data stops in the scenario that there is more, unrelated, data that follows. Consider the following made up file format:

File Format: MyFormat (MYFM) for example purposes only [int filetype: MYFM] [int version: 0] //0 - Version of MyFormat file format [int dataSize: 325] //The data section occupies the next 325 bytes [int checksumSize: 400] //The checksum section occupies 400 bytes after the data section (16 bytes each) [byte[] data] [byte[] checksum] 

This file contains a list of MyObject objects serialized into a byte stream and written to this file. This file has 325 bytes of MyObject objects, but without knowing the size of each MyObject you have no way of knowing which bytes belong to each MyObject . So, you define the size of MyObject on MyObject :

The MyObject data structure will occupy 13 bytes when written to the file as defined above. Knowing this, when reading our binary file, we can figure out dynamically how many MyObject objects follow in the file:

int dataSize = buffer.getInt(); int totalObjects = dataSize / MyObject.SIZE; 

This seems to be the typical usage case and argument for all uppercase static final constants, and I agree that in this context, all uppercase makes sense. Here’s why:

Java doesn’t have a struct class like the C language, but a struct is simply a class with all public members and no constructor. It’s simply a data struct ure. So, you can declare a class in struct like fashion:

Let me preface this example by stating I personally wouldn’t parse in this manner. I’d suggest an immutable class instead that handles the parsing internally by accepting a ByteBuffer or all 4 variables as constructor arguments. That said, accessing (setting in this case) this struct s members would look something like:

MyFileHeader header = new MyFileHeader(); header.fileType = buffer.getInt(); header.version = buffer.getInt(); header.dataSize = buffer.getInt(); header.checksumSize = buffer.getInt(); 

These aren’t static or final , yet they are publicly exposed members that can be directly set. For this reason, I think that when a static final member is exposed publicly, it makes sense to uppercase it entirely. This is the one time when it is important to distinguish it from public, non-static variables.

Note: Even in this case, if a developer attempted to set a final variable, they would be met with either an IDE or compiler error.

Summary

In conclusion, the convention you choose for static final variables is going to be your preference, but I strongly believe that the context of use should heavily weigh on your design decision. My personal recommendation would be to follow one of the two methodologies:

Methodology 1: Evaluate Context and Intention [highly subjective; logical]

• If it’s a private variable that should be indistinguishable from a private instance variable, then name them the same. all lowercase
• If it’s intention is to serve as a type of loose enum style block of static values, then name it as you would an enum . pascal case: initial-cap each word
• If it’s intention is to define some publicly accessible, constant, and static property, then let it stand out by making it all uppercase

Methodology 2: Private vs Public [objective; logical]

Methodology 2 basically condenses its context into visibility, and leaves no room for interpretation.

• If it’s private or protected then it should be all lowercase.
• If it’s public or package then it should be all uppercase.

Conclusion

This is how I view the naming convention of static final variables. I don’t think it is something that can or should be boxed into a single catch all. I believe that you should evaluate its intent before deciding how to name it.

However, the main objective should be to try and stay consistent throughout your project/package’s scope. In the end, that is all you have control over.

(I do expect to be met with resistance, but also hope to gather some support from the community on this approach. Whatever your stance, please keep it civil when rebuking, critiquing, or acclaiming this style choice.)

Solution 3

The language doesn’t care. What’s important is to follow the established styles and conventions of the project you’re working on, such that other maintainers (or you five months from now) have the best possible chance of not being confused.

I think an all-uppercase name for a mutable object would certainly confuse me, even if the reference to that object happened to be stored in a static final variable.

Solution 4

A constant reference to an object is not a constant, it’s just a constant reference to an object.

private static final is not what defines something to be a constant or not. It’s just the Java way to define a constant, but it doesn’t mean that every private static final declaration was put there to define a constant.

When I write private static final Logger I’m not trying to define a constant, I’m just trying to define a reference to an object that is private (that it is not accessible from other classes), static (that it is a class level variable, no instance needed) and final (that can only be assigned once). If it happens to coincide with the way Java expects you to declare a constant, well, bad luck, but it doesn’t make it a constant. I don’t care what the compiler, sonar, or any Java guru says. A constant value, like MILLISECONDS_IN_A_SECOND = 1000 is one thing, and a constant reference to an object is another.

Gold is known to shine, but not everything that shines is gold.

Solution 5

Well that’s a very interesting question. I would divide the two constants in your question according to their type. int MAX_COUNT is a constant of primitive type while Logger log is a non-primitive type.

When we are making use of a constant of a primitive types, we are mutating the constant only once in our code public static final in MAX_COUNT = 10 and we are just accessing the value of the constant elsewhere for(int i = 0; i

While in the case of non-primitive types, although, we initialize the constant in only one place private static final Logger log = Logger.getLogger(MyClass.class); , we are expected to mutate or call a method on this constant elsewhere log.debug(«Problem») . We guys don’t like to put a dot operator after the capital characters. After all we have to put a function name after the dot operator which is surely going to be a camel-case name. That’s why LOG.debug(«Problem») would look awkward.

Same is the case with String types. We are usually not mutating or calling a method on a String constant in our code and that’s why we use the capital naming convention for a String type object.

Источник