Le 1/30/13 10:29 AM, Steve Ulrich a écrit : > Hi! > Sorry, can't resist to respond on this, since i'm paranoid at programming ;-) > >> Emmanuel Lécharny [mailto:elecha...@gmail.com] wrote >> >> there are a lot of methods which have parameters with a 'final' >> keyword. >> It's most certaibly a IDE configuration, but it's really annoying. > It looks ugly, true. But I have seen so many method like: > > myMethod (Param parameter) { > ... > parameter = new Param(); > ... > }
Yes, me too, and I told the junior to review there code and lecture them so that they don't do the same mistake again. We aren't junior developpers, and I don't want to have to add such finals all over - even if the IDE does that for me - : t's just a waste of time, and makes the code ugly, so more painful to read, and I favor my own comfort over a potential error that never occurs in the code we write. > > IMHO Oracle should make parameter implicit final! Ys, and many other things that SUN - not Oracle - have missed would be great to have in Java. But it's not really a problem in this case. > I don't mark my parameters as final, because it makes the parameter list hard > to read. But I can understand anyone who does so! Same for me, but I don't understand why people does so. This is a dead stupid idea pushed by people who aren't confident with the code they have outsourced somewhere in asia for 5$ an hour... > >> Can those who have this configuration set in their IDE change it so >> that >> the committed code does not anymore contain the final keyword >> everywhere ? >> >> I personnaly think that the final keyword is useful in two cases : >> - for static fields, like in private statif final int CONSTANT = xxx >> - for variable thet are to be accessed by inner classes > - for (class/object) variables that are not expected to change anymore. > > Declaring an AtomicInteger as non-final is a potential threading issue! > Anyone could replace it with a new object, rendering the synchronisation > useless. > The same is true for concurrent collections, locks, monitors, etc. If you > don't expect (or want) it to change - make it final. > The use of local variables shouldn't be that complex, that they need a final > statement. This is a third case, I forgt about it, but this is a perfectly valid one. > >> Side note : >> I know that some may consider that using final for method parameters is >> a way to protect a stupid coder against a modification of a variable. >> Yeah, sure... But we are not stupid coders, are we ? > I'm writing perfect code, but somehow the code changes over time. When I'm > looking into my code a year later, it looks like a drunken monkey hit on a > keyboard ;-) I'm writing crappy code, and I know that, so I'm extra cautious. But I'm not relying on stupid rules as a safety belt... But this is just me :) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
