• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Constants (need your votes on best declaration)

 
Alex Belisle Turcot
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I've search on the board about the best way to define constants without success, even though the subect was discussed several times.


Is is bad practices to declare constant non-static ?

Please tell me which declaration is the best for the 3 samples below:

==> A string constant that should NOT be available from outside the class:


==> A constant that should be available from outside the class:


==> An object which I happen to never modify, should it be final then ?
==> The object does not *feel* like a constant however.


I read the sun coding standard, I would still like as many people's input as I can on this..

- Should final variables always be static ?
- Should final variables always be in uppercase ?
- Should all object never modified be final ?
- Should method's arguments be declared final as much as possible ?

Thanks in advance,
Alex
[ November 22, 2007: Message edited by: Alex Belisle Turcot ]
 
R van Vliet
Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Alex,

Ofcourse style (at least to a certain degree) is very subjective so consider the following nothing more than my personal views, so think "in my opinion" in front of everything :

1) Constants (that is, primary types or value objects the value of which you use as a constant value throughout the application lifecycle) should always be uppercase.

2) No class member variable that is only used within that class should be declared public, and only declared protected in quite specific circumstances.

3) The final keyword I feel is heavily underused. It's is extremely useful to improve code quality (i could fill a good chapter about the use of final but i wont). In this context though, the decision is actually fairly straightforward; if you know the value of the variable cannot or should not be changed, declare it final. On that note, I think a case can be made to uppercase variable names of non-final statics that behave as constants in every way other than actually being constant :



but there are better ways to do the above no doubt.

To answer the rest :

Originally posted by Alex Belisle Turcot:

- Should final variables always be static ?

Absolutely not, final variables do not have to be static. Consider the following code :



This guarantees that a Moose object will always have horns initialised after object construction. Note that this does not mean that horns cannot be null. It only guarantees that the horns variable has been explicitly set to a certain value (which is mentioned can be null).

Originally posted by Alex Belisle Turcot:

- Should final variables always be in uppercase ?


No, apart from removing the ability to set the variable after the object has been instantiated, final variables behave like any other variable and should use the normal camel notation in my opinion.

Originally posted by Alex Belisle Turcot:

- Should all object never modified be final ?


It's certainly an option provided you can initialize the variable in the constructor. If you need to initialize the variable later you can declare it private and not provide a setter with higher visibility.

Originally posted by Alex Belisle Turcot:

- Should method's arguments be declared final as much as possible ?


I dont really see why. Methods on average shouldnt really be longer than 15-25 lines so it doesnt really help code clarity (specifically, avoiding the mixing of method parameters and local variables). And modifying the value of method parameters is something that's useful quite often.

Also, the final keyword has often been mentioned as a way to improve code performance because short final methods are always inlined and such. During tests I've never actually noticed a performance difference and frankly I think current VMs are smart enough to decide what can be inlined and what can't without keywords helping it along.

[ November 22, 2007: Message edited by: R van Vliet ]
[ November 22, 2007: Message edited by: R van Vliet ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic