Coding standards - Uppercase constants
Roger Tobin Reyelts
were good coding standards, and why Sun picked the particular style it did.
Several people seemed dubious about the use of all upper-case to
define constants. For example, static final int FOO = 1; They didn't see
why these constants should be distinguished from any other members and
why the convention didn't seem to be strictly followed. For example, Color
defines constant members which aren't all upper case: Color.white, etc...
I believe that Sun chooses to emphasize _primitive_ constants,
because they differ from all other language members in that they have
compile time bindings. In other words, if I compile against FOO, I will
not receive a reference to FOO in my code, but instead, a constant 1. On
the other hand, when I bind against non-primitive constants, my code will
actually contain a reference to that constant.
This is, in fact, a very notable feature of the language. It means
that anytime a person defines a primitive constant, they must support that
constant, in perpetuity. In other words, that constant must never change
if the developer expects their code to be backwards binary compatible.
For some people, this may not be a big deal. But in many situations,
for example, Sun's, backwards binary compatibility is extremely important.
So, I feel that Sun is very justified in distinguishing constant primitives
from other types, and that it is a good practice in and of itself.
God bless,
-Toby Reyelts
--
Toby Reyelts
331107 Georgia Tech Station Atlanta Georgia 30332-1365
Internet: gt1...@prism.gatech.edu
Andrew R. Thomas-Cramer
That's excellent logic -- though the very first page I opened in "Java in a
Nutshell" to test it was the class listing for java.util.Locale, and other
exceptions are easy to find.
Still, the standard Java libraries do seem to follow this _usually_. And
Reyelt's reasoning for distinguishing primitive constants in code is sound.
Though I've been following the dominant style in Java, I'm not a fan of
uppercasing constants. I view it as an anachronism from pre-ANSI C, in which
constants were represented by macros, which were capitalized to warn the
reader they were macros. C++ and ANSI C provided real constants, removing
the need for the warning, but the style lingered on, with the usual level of
rationalization accompanying anachronisms. I find it humorous that Java's
brought us back to warning about the implementation of constants.
I guess this means I should stop capitalizing variable names referencing my
String constants? :)
Roger Tobin Reyelts wrote in message <8iatlo$h...@felix.cc.gatech.edu>...
xwil...@my-deja.com
message thru Deja.com? I have a question that my java applet is working
fine at my local IIS NT machine. but it's not working when I uploaded
it to the remote server. It shows anything but not run the java applet.
no error message reported.
thanks for help
Sent via Deja.com http://www.deja.com/
Before you buy.
Roger Tobin Reyelts
>That's excellent logic -- though the very first page I opened in "Java in a
>Nutshell" to test it was the class listing for java.util.Locale, and other
>exceptions are easy to find.
Maybe an example of a programmer who didn't read the style
guidelines? <smile>
>Still, the standard Java libraries do seem to follow this _usually_. And
>Reyelt's reasoning for distinguishing primitive constants in code is sound.
>
>Though I've been following the dominant style in Java, I'm not a fan of
>uppercasing constants. I view it as an anachronism from pre-ANSI C, in which
>constants were represented by macros, which were capitalized to warn the
>reader they were macros. C++ and ANSI C provided real constants, removing
>the need for the warning, but the style lingered on, with the usual level of
>rationalization accompanying anachronisms. I find it humorous that Java's
>brought us back to warning about the implementation of constants.
>
>I guess this means I should stop capitalizing variable names referencing my
>String constants? :)
Actually <grin>, Strings are a 'special case' exception to the
'primitive rule', because they also are 'lifted' at compile time.
(The real rule, which has no exceptions, is that anything that
lives in the constant pool will be lifted. Hence both primitives and
Strings are lifted.)
Thus, you'll want to leave your String constants' names in all
upper-case <smile>.
Surprisingly, many veteran programmers I've encountered are
surprised when they learn about this. I guess that is one more reason
to emphasize it in style.
elidan1
rrey...@cc.gatech.edu (Roger Tobin Reyelts) wrote:
>Andrew R. Thomas-Cramer <ar...@prism-cs.com> wrote:
>
>>That's excellent logic -- though the very first page I opened
in "Java in a
>>Nutshell" to test it was the class listing for
java.util.Locale, and other
>>exceptions are easy to find.
>
> Maybe an example of a programmer who didn't read the
style
>guidelines? <smile>
>
>
the day off when they gave out those guidelines :) <big smile>
elidan1
for mail null IS null
nulle...@nullzahav.net.il
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
Dale King
final primitives so do fit this definition of constant. But Sun
sometimes uses all-caps and sometimes not.
I guess we view the other uses of the convention like in Locale as
mistakes. Of course the problem with that is they go out of their way to
call them constants in the javadocs for Locale. There are other cases
where even public static final primitives aren't declared all-caps.
There are several in the Swing L&F stuff, but those are more internal
API's. The most common example would probably be serialVersionUID which
is a public static final long.
Usually, when the argument comes up someone will try to say it is
important so that you don't try to modify the constant. That argument
does not hold water since the compiler will catch those errors and that
would mean that the convention should be applied to non-static finals as
well, which it isn't.
The discussion where this was referenced though had more to do with the
fact that Sun did not explain the reasoning behind the edict. If this is
the justification, I can accept that (noting that there are many places
that disagree with this) but they should have stated that in the coding
standard.
"Andrew R. Thomas-Cramer" wrote:
>
> That's excellent logic -- though the very first page I opened in "Java in a
> Nutshell" to test it was the class listing for java.util.Locale, and other
> exceptions are easy to find.
>
> Still, the standard Java libraries do seem to follow this _usually_. And
> Reyelt's reasoning for distinguishing primitive constants in code is sound.
>
> Though I've been following the dominant style in Java, I'm not a fan of
> uppercasing constants. I view it as an anachronism from pre-ANSI C, in which
> constants were represented by macros, which were capitalized to warn the
> reader they were macros. C++ and ANSI C provided real constants, removing
> the need for the warning, but the style lingered on, with the usual level of
> rationalization accompanying anachronisms. I find it humorous that Java's
> brought us back to warning about the implementation of constants.
>
> I guess this means I should stop capitalizing variable names referencing my
> String constants? :)
>
> Roger Tobin Reyelts wrote in message <8iatlo$h...@felix.cc.gatech.edu>...
> > I believe that Sun chooses to emphasize _primitive_ constants,
> >because they differ from all other language members in that they have
> >compile time bindings. In other words, if I compile against FOO, I will
> >not receive a reference to FOO in my code, but instead, a constant 1. On
> >the other hand, when I bind against non-primitive constants, my code will
> >actually contain a reference to that constant.
--
--- Dale King
Recruiters: I am not willing to relocate outside of Indianapolis!
Roger Tobin Reyelts
>Static final strings do exhibit the same compile time behavior as static
>final primitives so do fit this definition of constant.
Looks like your news-server hadn't yet received my other article
explaining this in further detail before you posted. Take a look at it.
Fox
static final int FOO = 1;
so YOU could use foo or Foo anywhere else you please. I don't think
emphasis has anything to do with it.
I believe that they were being polite by accommodating most programmers
usual style of lowercase/mixedcase variable assignments.
At least, that would be my reasoning. Personally, I think people should
code in whatever style they are most comfortable. Consistency is the
most important thing.
Fox
*************
Roger Tobin Reyelts wrote:
>
> There was a raging debate in this forum about what coding standards
> were good coding standards, and why Sun picked the particular style it did.
>
> Several people seemed dubious about the use of all upper-case to
> define constants. For example, static final int FOO = 1; They didn't see
> why these constants should be distinguished from any other members and
> why the convention didn't seem to be strictly followed. For example, Color
> defines constant members which aren't all upper case: Color.white, etc...
>
> I believe that Sun chooses to emphasize _primitive_ constants,
> because they differ from all other language members in that they have
> compile time bindings. In other words, if I compile against FOO, I will
> not receive a reference to FOO in my code, but instead, a constant 1. On
> the other hand, when I bind against non-primitive constants, my code will
> actually contain a reference to that constant.
>
> This is, in fact, a very notable feature of the language. It means
> that anytime a person defines a primitive constant, they must support that
> constant, in perpetuity. In other words, that constant must never change
> if the developer expects their code to be backwards binary compatible.
>
> For some people, this may not be a big deal. But in many situations,
> for example, Sun's, backwards binary compatibility is extremely important.
> So, I feel that Sun is very justified in distinguishing constant primitives
> from other types, and that it is a good practice in and of itself.
>
Roger Tobin Reyelts
>I believe they used:
> static final int FOO = 1;
>
>so YOU could use foo or Foo anywhere else you please. I don't think
>emphasis has anything to do with it.
>
>I believe that they were being polite by accommodating most programmers
>usual style of lowercase/mixedcase variable assignments.
Huh?
Andrew R. Thomas-Cramer
Fox wrote in message <39498C47...@eatel.net>...
>I believe they used:
> static final int FOO = 1;
>
>so YOU could use foo or Foo anywhere else you please. I don't think
>emphasis has anything to do with it.
That is one justification cited in the JLS:
Constant names normally have no lowercase letters, so they will not
normally
hide names of packages, types, or fields, whose names normally
contain at
least one lowercase letter.