Hardcore Java - The Final Story
I recently read this chapter (free sample of course) of the book called Hardcore Java By Robert Simmons, Jr. Although the book got an average 3 out of 5, I personally found this chapter very interesting. The chapter is solely about the use of the keyword final and how using it can benefit your code, which I found surprising because I never really made variables final before and I also didn't see many/any final variables in other peoples code (except maybe in a method or two)
here is the link to the second chapter
http://www.oreilly.com/catalog/hardcorejv/chapter/ch02.pdf
There are a few quick benefits to making your variables final as the chapter describes, the main advantages that stick in my mind our
1. It stops you accidentally assigning a value to variable you don't want to change (by making it final) the compiler will complain if you try to assign a value to this variable. The main example I can think of, is variables that are incoming parameters. Good programming standards usually tell you not change this and by making them final you can't
2. it shows other developers who will look at your code later that they shouldn't assign values to variables marked private.
3. Finally it may have some benefits of taking up less memory (although method scope variables are not substituted at compile time)
The chapter goes into a far bit of detail but I never felt it to be very boring. The main point that struck me was that by making some variables final you bring the errors of assigning to a variable you don't mean to, too compile time rather than having to search for it at runtime.
Since reading this article I have gone a bit final mad and it has been surprising just how many variables you create and then don't change.
try it, you might like it. I would be interested to hear from anyone who has read the book to see how they found the rest of it as I am quite tempted to purchase it.
This blog entry is also on the same sort of topic so if you like this you should read this blog entry which is about why you should use the this keyword
here is the link to the second chapter
http://www.oreilly.com/catalog/hardcorejv/chapter/ch02.pdf
There are a few quick benefits to making your variables final as the chapter describes, the main advantages that stick in my mind our
1. It stops you accidentally assigning a value to variable you don't want to change (by making it final) the compiler will complain if you try to assign a value to this variable. The main example I can think of, is variables that are incoming parameters. Good programming standards usually tell you not change this and by making them final you can't
2. it shows other developers who will look at your code later that they shouldn't assign values to variables marked private.
3. Finally it may have some benefits of taking up less memory (although method scope variables are not substituted at compile time)
The chapter goes into a far bit of detail but I never felt it to be very boring. The main point that struck me was that by making some variables final you bring the errors of assigning to a variable you don't mean to, too compile time rather than having to search for it at runtime.
Since reading this article I have gone a bit final mad and it has been surprising just how many variables you create and then don't change.
try it, you might like it. I would be interested to hear from anyone who has read the book to see how they found the rest of it as I am quite tempted to purchase it.
This blog entry is also on the same sort of topic so if you like this you should read this blog entry which is about why you should use the this keyword
If you like this blog or and fancy something a bit less technical with some laughing thrown in then check out my other blog Amusing IT Stories. Which is a blog about funny and amusing stories from the IT environment and the office. It is a mix of news, office humour, IT stories, links, cartoons and anything that I find funny
posted by The Hosk at
9:30 pm
7 Comments:
I agree with what you say and same thing goes with Checkstyle. I personally final as many variables that I can. Its not for performance, but just to ensure that I don't do anything stupid with the variable inadvertently. It helps when you are maintaining excessively long methods and you want to make sure you don't trample on any data.
It is also useful to make sure your classes are immutable. I tend to sprinkle private finals in the class to ensure that the constructor sets all the necessary variables. I don't like having setters if I can avoid them.
By
Archimedes Trajano, at Mon May 01, 02:15:00 pm 2006
I have just read about making classes immutable in Effective Java. It's a simple but excellent idea, which can stop you worrying and writing code to make sure values haven't been set to stupid values etc.
I totally agree with your point, making variables final stops you assigning a value to them and it's hard to see why you wouldn't set them to be final.
It's a bit wierd to start with but when I thought about it, it makes perfect sense and helps you to design better code because you think about whether data needs to change or not.
excellent comment, thanks for contributing
By
The Hosk, at Mon May 01, 02:53:00 pm 2006
Parameters are sometimes better non-final.
int returnSomething(final int x,final int y)
{
final int newX=x+30;
final int newY=y+20;
return x*y; //oops, should be newX*newY
}
The problem above is that there are too many variables* - the parameters need processing before work, but because I was adhering to a broken code standard that says that parameters should always be final, I introduced a bug. This time I did it on purpose. Maybe you will do it by accident sometime.
*parameters are variables too!
I prefer this - there are no irrelevant variables/parameters around:
int returnSomething(int x,int y)
{
x+=30;
y+=20;
return x*y;
}
The only person this confuses is the person who assumes that Java has pass by reference, which it doesn't. Let's write for good programmers, not twits.
Archimedes' suggestion about private final fields - No. Make your implementation classes anonymous classes, then the 'fields' are definitely always assigned, definitely always final (until Java 7), and there is less meaningless code to write.
E.g.,
final double real=whatever;
final double imag=whatever;
return new Complex()
{
public double real()
{
return real;
}
public double imag()
{
return imag;
}
};
By
Ricky Clarkson, at Fri Oct 20, 09:57:00 am 2006
why did you need to assign the parameters passed in to new parameters if you weren't changing their values.
The final paramters stops you assigning values to the parameters passed in, which is probably not something you would want to do.
I didn't really think problems arise from just using parameters but bugs occur from assigning parameters to the wrong variables e.g. the ones passed in.
By
The Hosk, at Fri Oct 20, 02:19:00 pm 2006
I always use the following dumb rule: everything is final (classes, members, variables and parameters) as long as nothing proves the opposite.
By
Anonymous, at Fri Nov 10, 12:44:00 am 2006
I like making local and member variables final, but for me, doing the same for method parameters is going overboard. Chances are, it doesn't do what you want it to anyway.
In the example above, making an int parameter final keeps you from messing with it inside of the method, but you can't permanently change it anyway because primitives are passed by value.
Making an Object parameter final just keeps you from assigning a totally new object to it. The final keyword doesn't stop you from modifying any of the Object's contents.
By
Anonymous, at Fri Nov 10, 03:46:00 pm 2006
you are right about making Object parameters final but at least if you see it's final someone might think twice about changing a value to it.
By
The Hosk, at Fri Nov 10, 04:25:00 pm 2006
Post a Comment
<< Home