Naming conventions for final variables

K

Karsten Wutzke

Hi all!

I know this has been discussed, but I couldn't find the answers I was
looking for.

Final constants are supposed to be all UPPER_CASE using underscores.
For int's this is all ok. However, should you also name String's,
File's, Properties', JTextField's etc. in the same way?

Examples:

private static final String STR_APP_VERSION = "0.1a";

private static final String STR_VERSION =
System.getProperty("java.version");

private static final File FL_ROOT_DIR = new
File(System.getProperty("user.dir")).getAbsolutePath();
private static final String STR_IMAGES_DIR_NAME = "images";
private static final File FL_IMAGES_DIR = new File(FL_ROOT_DIR,
STR_IMAGES_DIR_NAME);

private static final Properties PRP = new Properties();

public static save(final UserData UD)
{
File flUserData = UD.getFile();

... //some anonymous inner class defined accessing UD
}

Anybody reading this should note I use some prefixing naming
convention for all *non-final* variables (the main reason for this
"Hungarian notation" is not having to think about new identifiers when
creating associated objects, main use is for all those JLabels,
JTextFields, JPanels, JButtons etc. in a GUI see last example):

String strFirstName = "Dale"; // ;-)

private File flSearchDir = new File(FL_ROOT_DIR, strDirName); //
strDirName might be a local var

Properties prpTempUserData = new Properties();

UserData udOld = UserData.getInstance();

JLabel lbAge = new JLabel("Age:");
SpinnerNumberModel snmAge = new SpinnerNumberModel(userAge, 16, 70,
1); //userAge is some int
spnAge = new JSpinner(snmAge);
JPanel pnAge = GuiFactory.createFlowPanel(lbAge, spnAge);
pn.add(pnAge);

As seen above, for all *final* class instance variables I try to keep
the equivalent prefix notation: STR_FIRST_NAME, FL_SEARCH_DIR,
PRP_TEMP_USER_DATA, TF_FIRST_NAME, ...

But the question is: Is it necessary? Is it recommended? All
discussions I read so far, including Sun's naming conventions propose
UPPER_CASE for all 'constants'. The examples I saw only include
*int*'s though.

How is a 'constant' defined anyway? Is it equivalent to 'final'? Why
should I name only int's uppercase and name all final *class
instances* in mixed case? To stay consistent I started naming all
final variables in UPPER_CASE, but anytime I change the final
attribute I also have to rename the variable, which only just wastes
my time...

Furthermore, naming all final variables of all class instances
UPPER_CASE somehow looks strange in my editor , especially when syntax
highlighting for final variables is on... I could change that anytime
of course, but the main question is, should I name all final variables
UPPER_CASE or just int's (and/or simple types)?

As an exception to the rule, I might consider not just naming final
int's UPPER_CASE etc. but also String's used *only* as keys for
identifying objects in HashMap's, the Preferences API etc.

I find that hard to decide...

Opinions?

TIA
Karsten
 
T

Tom Hawtin

Karsten said:
Final constants are supposed to be all UPPER_CASE using underscores. ^static
For int's this is all ok. However, should you also name String's,
File's, Properties', JTextField's etc. in the same way?

Anything that is mutated almost certainly shouldn't be referable by statics.
How is a 'constant' defined anyway?

The JLS defines a 'compile-time constant'. However the definition of
that is very restrictive.
Is it equivalent to 'final'?

No. Certainly a constant field must be both final and static. It must
also refer to a value that doesn't change. For instance if the type is
Map, then no entries should be added, removed or updated on that map.
Certainly if the field is non-private, the no-change policy should be
enforced, say with Collections.unmodifiableMap.
Why
should I name only int's uppercase and name all final *class
instances* in mixed case?

The colour constants in java.awt.Color are an example where there were
lower case constants, then later versions added upper case equivalents.
To stay consistent I started naming all
final variables in UPPER_CASE, but anytime I change the final
attribute I also have to rename the variable, which only just wastes
my time...

I think most mainstream IDEs allow relatively simple renaming of
variables (though perhaps with a bad UI).

Tom Hawtin
 
A

Andrew Thompson

Karsten wrote;
Tom Hawtin wrote: ...

The colour constants in java.awt.Color are an example where there were
lower case constants, then later versions added upper case equivalents.

I just noted (about to have a rant, but checking first),
that Sun had finally gotten around to adding @since
tags to the upper case Color's in the 1.6 JavaDocs
(neither 1.4 nor 1.5 made any mention of it, AFAIR).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,582
Members
45,057
Latest member
KetoBeezACVGummies

Latest Threads

Top