Java naming convention for static final variables

Question

there is a rule which says      Names representing constants  final variables  must be all uppercase   using underscore to separate words    taken from http   geosoft no development javastyle html    that works fine for primitive types like int or strings   private static final int MAX COUNT   10    But what s about non primitive types  In most cases I ve seen the following   private static final Logger log   Logger getLogger MyClass class     or in singletons  where instance variable is not in upper case   The question is what is the right way to declare those types of variables  like log and instance

User · Answer

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.

User · Answer

Don t live fanatically with the conventions that SUN have med up  do whats feel right to you and your team    For example this is how eclipse do it  breaking the convention  Try adding implements Serializable and eclipse will ask to generate this line for you   Update  There were special cases that was excluded didn t know that  I however withholds to do what you and your team seems fit

User · Answer

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

User · Answer

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   interface ProcessStates     int PS RUNNING   0    int PS SUSPENDED   1          Obscuring involving constant names is rare          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

User · Answer

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 lt MAX COUNT  i     This is the reason we are comfortable with using this convention   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

User · Answer

In my opinion a variable being  constant  is often an implementation detail and doesn t necessarily justify different naming conventions  It may help readability  but it may as well hurt it in some cases

User · Answer

These variables are constants  i e  private static final whether they re named in all caps or not   The all-caps convention simply makes it more obvious that these variables are meant to be constants  but it isn t required   I ve seen   private static final Logger log   Logger getLogger MyClass class     in lowercase before  and I m fine with it because I know to only use the logger to log messages  but it does violate the convention   You could argue that naming it log is a sub-convention  I suppose   But in general  naming constants in uppercase isn t the One Right Way  but it is The Best Way

User · Answer

There is no  right  way -- there are only conventions  You ve stated the most common convention  and the one that I follow in my own code  all static finals should be in all caps  I imagine other teams follow other conventions

User · Answer

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   public class ChatMessage       private final Logger logger   LoggerFactory getLogger getClass         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- gt int and int- gt 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   public enum Error       SUCCESS 0       TOOLONG 1       ILLEGALCHARACTERS 2       Instead  we do the following   public enum Error       Success 0       TooLong 1       IllegalCharacters 2       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   public class MyObject       private final long id    It has a 64bit identifier   8 bytes      private final int value    It has a 32bit integer value   4 bytes      private final boolean special    Is it special    1 byte       public static final int SIZE   13    8   4   1   13 bytes     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 structure  So  you can declare a class in struct like fashion   public class MyFile       public static final int MYFM   0x4D59464D     MYFM  another use of all uppercase         The struct     public static class MyFileHeader           public int fileType   MYFM          public int version   0          public int dataSize   0          public int checksumSize   0            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 structs 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

[java] Java naming convention for static final variables

Examples related to java

Examples related to coding-style