 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / First Aid / March 2008Naming conventions for constants
Hello, Sun and other sources state that constants should be named in ALL_UPPER_CASE. This is ok, but what the hell is a constant? Someone stated some time ago constants only apply to 'static final fields' being simple types like int, String, Color etc. What if I have a protected static final Properties ... = new Properties()? Write the field in ALL_UPPER_CASE like PRP or PROPS? It it just me or do I get eye cancer here? Aren't constants declarations which involve mostly immutable classes/ objects? The int in itself can't be changed once declared final, final instances of some class are basically mutable given certain access methods, so String's, awt.Color's should *not* be called constants strictly, but can be considered immutable. Other classes used like collections, Properties and custom classes are definitely inherently mutable and (to answer the above question myself) should not be declared in UPPER_CASE. I'm unsure for which declarations this convention is meant for... What about final parameters? What about final local variables? Remember these cannot be declared as static, so logically 'constants', if said to be static only, never apply to parameters and local variables... Can anyone confirm that please? Discussions welcome. Karsten >Sun and other sources state that constants should be named in >ALL_UPPER_CASE. This is ok, but what [...] is a constant? You should not write the omitted words »[...]«, because they are not relevant for the topic and distract the reader. >Someone stated some time ago constants only apply to 'static final >fields' being simple types like int, String, Color etc. »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.« Java Language Specification, Third Edition, 6.8.6 > >Sun and other sources state that constants should be named in > >ALL_UPPER_CASE. This is ok, but what [...] is a constant? > > You should not write the omitted words »[...]«, because they > are not relevant for the topic and distract the reader. No need to comment that, right...? > >Someone stated some time ago constants only apply to 'static final > >fields' being simple types like int, String, Color etc. [quoted text clipped - 6 lines] > > Java Language Specification, Third Edition, 6.8.6 Well, I don't like the idea for class instances that are by themselves used as mutable objects. I will only do this for simple types, ints, Strings, Colors and some other few. Thanks Karsten > Sun and other sources state that constants should be named in > ALL_UPPER_CASE. This is ok, but what the hell is a constant? I'd say constants are things that *you* the programmer *intend* to be constant. Properties is only constant if that's how you think you are using it. Given what a Properties object really is, I'd think normally you wouldn't want to use it like that. Other things could be constant in some instances and not in others. Well, int's are a pretty good example. Some times they get used as a constant, most often they are not. Use all upper case to denote your intent. It's there to help the person reading your code so they know what you meant to do. >Sun and other sources state that constants should be named in >ALL_UPPER_CASE. This is ok, but what the hell is a constant? Anything static final. It is an ugly convention. I sometimes violate the convention for something that is a static final, but is not a constant in the sense of a configuration int or String, e.g. a HashMap that is allocated once and for all statically.  SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com On 16 Mrz., 07:03, Roedy Green <see_webs...@mindprod.com.invalid> wrote: > >Sun and other sources state that constants should be named in > >ALL_UPPER_CASE. This is ok, but what the hell is a constant? > > Anything static final. It is an ugly convention. Yap. So any final local variables are mixedCased... > I sometimes violate > the convention for something that is a static final, but is not a > constant in the sense of a configuration int or String, e.g. a HashMap > that is allocated once and for all statically. I like that! Same opinion here. I'll do it that way, too... Thanks Karsten > On 16 Mrz., 07:03, Roedy Green <see_webs...@mindprod.com.invalid> > wrote: [quoted text clipped - 4 lines] > > Yap. So any final local variables are mixedCased... That was never in question, since the convention of ALL_UPPER_CASE applies only to static variables. >> I sometimes violate >> the convention for something that is a static final, but is not a >> constant in the sense of a configuration int or String, e.g. a HashMap >> that is allocated once and for all statically. > > I like that! Same opinion here. I'll do it that way, too... For that one I'd use camel case, since a HashMap exists only to be modified. The coding conventions <http://java.sun.com/docs/codeconv/> specifically call for *class constants* to be spelled in all upper case. <http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367> Note that the JLS says "may conventionally be", not "should be" nor "must be" for using all upper case on final class variables. Furthermore, the section in the JLS, § 6.8.6, is entitled "Constant Names", not "Final Variable Names". The "correct" convention is to spell static constant names with all upper-case letters, other variables (final or not) with mixed case. People do ("may conventionally") shade the rule to use all upper case to name final statics where they are used immutably even if the object isn't a constant. <http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.12.4> > We call a variable, of primitive type or type String, that is final and > initialized with a compile-time constant expression (§15.28) a constant variable. <http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.28> When enums were added, the convention was extended to enum constants, as illustrated in the JLS § 8.9. SignatureLew >For that one I'd use camel case, since a HashMap exists only to be modified. The reference is a constant final, but the HashMap itself is usually quite mutable. Further the reference is not in principle final. It just happens to be for now. True constants are not just unchanged for now, they are unchanging in principle. For those reasons, like Lew, I don't feel guilty using camel case for static final HashMap hashMap... SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.