Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (524)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (592)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Which is better?  (Read 6885 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #30 - Posted 2010-11-26 13:28:10 »

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

Cas Smiley

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #31 - Posted 2010-11-29 20:21:27 »

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

Cas Smiley
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.

See my work:
OTC Software
Offline JL235

JGO Coder


Medals: 10



« Reply #32 - Posted 2010-11-30 10:30:43 »

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!
Legends of Yore - The Casual Retro Roguelike
Offline Spasi
« Reply #33 - Posted 2010-11-30 18:44:19 »

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.
Offline Nate

« JGO Bitwise Duke »


Medals: 158
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #34 - Posted 2010-11-30 20:45:53 »

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). Smiley

Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #35 - Posted 2010-11-30 21:01:58 »

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

Cas Smiley

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #36 - Posted 2010-11-30 21:34:58 »

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 Smiley).

Offline zammbi

JGO Coder


Medals: 4



« Reply #37 - Posted 2010-11-30 22:34:29 »

Quote
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.


Current project - Rename and Sort
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #38 - Posted 2010-11-30 22:42:20 »

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 Wink

Cas Smiley

Offline Nate

« JGO Bitwise Duke »


Medals: 158
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #39 - Posted 2010-12-01 08:16:13 »

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 Wink
And closures. Otherwise totally agreed.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline zammbi

JGO Coder


Medals: 4



« Reply #40 - Posted 2010-12-01 10:37:15 »

Quote
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  Roll Eyes http://renaud.waldura.com/doc/java/final-keyword.shtml

Current project - Rename and Sort
Online Roquen
« Reply #41 - Posted 2010-12-01 11:03:46 »

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

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #42 - Posted 2010-12-01 12:37:12 »

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

Cas Smiley

Offline tom
« Reply #43 - Posted 2010-12-01 12:56:43 »

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.

Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #44 - Posted 2010-12-01 12:58:28 »

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 Smiley

Online Roquen
« Reply #45 - Posted 2010-12-01 13:16:32 »

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.
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #46 - Posted 2010-12-01 13:52:21 »

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

Cas Smiley

Online Roquen
« Reply #47 - Posted 2010-12-01 14:38:28 »

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).
Offline Spasi
« Reply #48 - Posted 2010-12-01 15:04:21 »

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.
Offline JL235

JGO Coder


Medals: 10



« Reply #49 - Posted 2010-12-01 15:11:35 »

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.

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 78
Projects: 15


★★★★★


« Reply #50 - Posted 2010-12-01 15:16:46 »

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.
Offline pjt33
« Reply #51 - Posted 2010-12-01 15:51:52 »

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.
Offline Spasi
« Reply #52 - Posted 2010-12-01 16:14:07 »

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.
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #53 - Posted 2010-12-01 17:14:45 »

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?

See my work:
OTC Software
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #54 - Posted 2010-12-01 17:55:43 »

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

Cas Smiley

Offline Spasi
« Reply #55 - Posted 2010-12-01 19:03:41 »

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).
Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

SHC (24 views)
2014-11-25 12:00:59

SHC (24 views)
2014-11-25 11:53:45

Norakomi (22 views)
2014-11-25 11:26:43

Gibbo3771 (22 views)
2014-11-24 19:59:16

trollwarrior1 (36 views)
2014-11-22 12:13:56

xFryIx (74 views)
2014-11-13 12:34:49

digdugdiggy (52 views)
2014-11-12 21:11:50

digdugdiggy (46 views)
2014-11-12 21:10:15

digdugdiggy (41 views)
2014-11-12 21:09:33

kovacsa (69 views)
2014-11-07 19:57:14
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!