A Final Bit Of Advice
Or maybe that should be “a bit of final advice”. :) There was a question on StackOverflow about best practices around using final in parameters, local variables, fields, etc and my answer seems to have been popular. I’ll repeat it here merely to make it easier for me to find later.
Obsess over:
- Final fields - Marking fields as final forces them to be set by end of construction, making that field reference immutable. This allows safe publication of fields and can avoid the need for synchronization on later reads. (Note that for an object reference, only the field reference is immutable - things that object reference refers to can still change and that affects the immutability.)
- Final static fields - Although I use enums now for many of the cases where I used to use static final fields.
Consider but use judiciously:
- Final classes - Framework/API design is the only case where I consider it.
- Final methods - Basically same as final classes. If you’re using template method patterns like crazy and marking stuff final, you’re probably relying too much on inheritance and not enough on delegation.
Ignore unless feeling anal:
- Method parameters and local variables - I RARELY do this largely because I’m lazy and I find it clutters the code. I will fully admit that marking parameters and local variables that I’m not going to modify is “righter”. I wish it was the default. But it isn’t and I find the code more difficult to understand with finals all over. If I’m in someone else’s code, I’m not going to pull them out but if I’m writing new code I won’t put them in. One exception is the case where you have to mark something final so you can access it from within an anonymous inner class.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Tags:
Comments
Peter Huber replied on Thu, 2008/11/27 - 4:22am
Suggestion for "Method parameters and local variables"
If your just lazy then eclipse > source > clean up is what you're looking for.
I personally use final whereever I can, even for parameters and local variables. Why? I see it as some sort of communication in a team-development-environment. In such a environment you might find arbitrarily long methods (though it is a bad smell such cases exist in reality) and in such methods some programmers might find it useful to reuse parameters and variables (bad smell, too) that other team-members have introduced before. Reuse in on place might break the code in another place. If the programmer with a "plan to reuse" finds the objects final then there will be a compiler-warning which raises the question "stop! is that what I'm doing right? what is behind this final variable, I might take a closer look".
And I guess though I really don't know that a intelligent java-compiler might use the "final" attribute to do some sort of optimization, even for parameters and lokal variables...
Alex Miller replied on Thu, 2008/11/27 - 10:49am
Raveman Ravemanus replied on Thu, 2008/11/27 - 11:25am
Shams Mahmood replied on Thu, 2008/11/27 - 6:06pm
One scenario where finals may be useful is in avoiding the silliest of errors in setters :)
public void setName(String name) {name = name;
}
Admitted this can be avoided using good naming conventions like using 'm' and 'p' prefixes for member variables and parameters.
Another reason I use finals is to ensure that the method uses the parameter/local variable I have initialized and avoid erroneous reassignments.
Walter Laan replied on Fri, 2008/11/28 - 9:46am
The (Eclipse) compiler can check for those conditions and give a warning (or error) if you want, which I prefer over final or name prefixes.
public void setName(String name) {
this.name = name;
}
// is much clearer than:
public void setName(final String pName) {
mName = pName;
}
Murali VP replied on Mon, 2008/12/01 - 11:31pm
>>I RARELY do this largely because I’m lazy and I find it clutters the code.
This is just a personal preference, I don't see it as a clutter, for scenarios like the setName, it is as a matter of fact, essential. So please don't call your article as "advice" when some parts of it are actually not, unless you want to give a bad advice.
Alex Miller replied on Tue, 2008/12/02 - 12:18am
in response to:
Murali VP