Which is better?

[princec]

Why would you waste your fingers on typing "final" there?

Cas

[Eli Delventhal]

Why would you waste your fingers on typing "final" there?

Cas

I would guess he's doing it so that you're very clear that variable can only be assigned once. However, I'd argue that his code is perhaps more confusing - I always as a rule assign constants on the line they are defined, because anything else looks wrong to me.

[JL235]

I make all my variables final unless they need to be none final. Knowing that a variable will never change makes decoding my code later much easier because I don't have to worry about tracking it. Now a non-final variable is clearly going to be altered within an algorithm. Essentially it's more obvious which bits will change and which won't.

I have used a few functional languages and so kinda like the trust you can have in the way that a variable will never change.

Games published by our own members! Check 'em out!

[Spasi]

I make all my variables final unless they need to be none final. Knowing that a variable will never change makes decoding my code later much easier because I don't have to worry about tracking it. Now a non-final variable is clearly going to be altered within an algorithm. Essentially it's more obvious which bits will change and which won't.

I have used a few functional languages and so kinda like the trust you can have in the way that a variable will never change.

+1. 90% of the variables and method parameters I declare are final. Even more if you ignore loop variables (enhanced for helps too). Actually, my code would be much cleaner if all variables were implicitly final and there was a "mutable" keyword instead.

[Nate]

final, FTL! It is just clutter on parameters and local. It isn't harder to debug with non-final variables. Unless you need final for scoping, you're just wasting your time (and mine when I have to read it).

[princec]

Indeed, it's really not hard to see where something is being assigned. Adding final all over the place is just more clutter!

Cas

[erikd]

If java would be invented now, I'd vote for final being the default as I declare everything final by default. Maybe it's clutter, but it's concise and clear.
Now that final isn't default, I think it would help if Eclipse's (or any IDE's) syntax colouring would distinguish between final and non-final variables (I'd colour non-final variables orange, probably ).

[zammbi]

I'd vote for final being the default as I declare everything final by default.

Agreed.
I set everything as final. I find it helps a little to prevent bugs.

[princec]

It prevents no bugs at all and makes your code hideous. There's only one place final should be used, and that's for security related purposes to prevent overriding critical methods or classes. Which means for us ordinary developers it has no purpose at all. Except constants

Cas

[Nate]

It prevents no bugs at all and makes your code hideous. There's only one place final should be used, and that's for security related purposes to prevent overriding critical methods or classes. Which means for us ordinary developers it has no purpose at all. Except constants

And closures. Otherwise totally agreed.

Games published by our own members! Check 'em out!

[zammbi]

It prevents no bugs at all and makes your code hideous.

Well I found it has helped a little.


For those who want to read up on the final keyword, this site is good on explaining the goodness  http://renaud.waldura.com/doc/java/final-keyword.shtml

[Roquen]

Don't forget that final provides information that cannot otherwise be know to the runtime compiler.

[princec]

Very little information the compiler can't already know itself.

Cas

[tom]

I've also started using final, at least on member variables. It saves me the time do a bunch of "find usages" when I want to change an existing class and I need to know what changes to take care of any side effects. Also encourages more immutable code, which I think is a good thing.

[princec]

member variables - fine - has genuinely useful meaning such as immutable objects and known construction state (although there are caveats)
Local variables and parameters - code clutter the compiler already optimises anyway.

Cas

[Roquen]

I'm anal and define methods 'final' even if they are implicitly final.

If a method is not final (either implicit or explicit), it cannot be inlined nor the method table indirection skipped.  The runtime cannot know that it is never overwritten.  Keep in mind the dynamic nature of Java.  Say you have a package private class which has no subclass at time T.  There are perfectly legal ways for a new class that does extend it at some future time to be introduced.

WRT members, it's one less piece of information that the compiler must deduce.  Variable lifetime and assignment analysis isn't free.

[princec]

Hm, I thought you knew a bit more about how Hotspot worked?

Cas

[Roquen]

I'm assuming that HotSpot isn't the only game in town.  Yes, the deoptimization code base is pretty cool. (For others, HotSpot can treat non-final methods as final.  If a new class is loaded and proves that assuming incorrect, the wrong code is ejected and recompiled).

[Spasi]

It's perfectly fine for people to either hate or like the final keyword on local vars or method parameters. It's a code style and each programmer knows what code style works for them. The Java compiler removes it from local vars and params anyway, it has no value at runtime.

I generally skip final for methods that are implicitly final. Otherwise it depends on the API, during the design phase I usually use final everywhere until there's a reason not to. Tests and actual usage of the API will dictate whether a method requires final or not. For public APIs though I try to be very careful with final usage, it can be very annoying for the API user.

I may try to create a "Java" with the mutable keyword and maybe operator overloading with MPS, when I have time.

[JL235]

I just want to distance myself from the performance argument. This is really bad and misunderstood reason to use final. There are plenty of non-final things which can prevent methods from being inlined and there is nothing to stop a compiler inlining a non-final method (such as if it's reentrant).

People can come up with theoretical arguments as to why Java can't optimize a non-final method or class, but because optimizations are performed at runtime there is also nothing to stop them being unrolled and re-optimized at runtime.

Google's V8 JavaScript engine does this. It optimizes your code presuming a range of corner cases will not occur, which allows it to perform more aggressive optimizations. If you hit one of those corner case then it throws away the optimized code and you get terrible performance. But for 99.9% of JS out there this strategy works and improves performance. There is no reason why a Java runtime can't do the same (and I believe HotSpot already does in some cases).

I also second that variables should be final unless declared 'mutable', and would also like to see non-final local variables colored differently. As Cas said there is nothing to stop you looking through looking for an assignment, especially with the variable highlighting you get in IDEs now. But I'd rather that I could be told this information in _one_ place without having to look anywhere else. Final does this.

However for methods and classes I try to avoid using final unless I have a good reason to.

[kappa]

Personally can't stand code with final littered all over the place, guess this is just one of those pet peeves that gets under programmers skins, much like the age old debate of whether an opening bracket of a method should be on the same line or the next line.

But yeah agreed that its just a matter of style.

However many that I have spoken to that use it are under the impression that it improves performance of the code somehow or that it reduces garbage.

[pjt33]

I have found myself missing final local variables in C# when refactoring complex legacy code. It gives you a foolproof way of checking whether something is modified later in a far-too-large method.

[Spasi]

There is no reason why a Java runtime can't do the same (and I believe HotSpot already does in some cases).

I think HotSpot can even do it without throwing away the optimized code path.

and would also like to see non-final local variables colored differently.

IDEA supports using different styles for reassigned local variables and method parameters. Not exactly what you describe but equally useful.

@kapta: Have you checked if there's a plugin for your favorite IDE that allows you to hide final from local vars and params? Would be nice for people that dislike final.

[Eli Delventhal]

I have found myself missing final local variables in C# when refactoring complex legacy code. It gives you a foolproof way of checking whether something is modified later in a far-too-large method.

Perhaps deal with the real problem and shorten the method instead?

[princec]

Quite! Big methods make code hard to read and understand. I know because loads of my code looks like this

Cas

[Spasi]

That's another reason I like final method parameters actually. When I find myself wanting to reassign a parameter, I always try to rethink wth it is I'm trying to do (and usually split a method in smaller ones). With many small methods there's almost never a need to reassign a parameter.

edit: Btw, my IDE automatically generates the final keyword when it generates method stubs, so I don't actually waste time typing it. As for readability, I don't mind the final keywords on methods with few arguments and on methods with lots of arguments I usually need to go through the javadoc to figure out what's happening (lots of arguments is usually a sign of bad design anyway).