Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!news.glorb.com!news.netfront.net!not-for-mail From: Wanja Gayk Newsgroups: comp.lang.java.programmer Subject: Re: Style Police (a rant) Date: Sat, 10 Sep 2011 06:45:33 +0200 Organization: Netfront http://www.netfront.net/ Lines: 58 Message-ID: References: NNTP-Posting-Host: 93.130.27.244 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: adenine.netfront.net 1315629933 48505 93.130.27.244 (10 Sep 2011 04:45:33 GMT) X-Complaints-To: news@netfront.net NNTP-Posting-Date: Sat, 10 Sep 2011 04:45:33 +0000 (UTC) User-Agent: MicroPlanet-Gravity/3.0.4 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:7761 In article , janburse@fastmail.fm says... > > Eric Sosman schrieb: > > BUT if you have a concrete non-final method that actually *does* > > something, you have not "designed for extension." It's all in aid of > > somebody's theory about programming style: You're all right as long as > > I have noticed that final methods sometimes execute faster > than non-final methods. The final modifier gives a hint to > the optimizers. Well, that myth is well debunked and if you're measuring some significant speeduph, maybe you should double check very closely what you're measuring (i.e. the "currentTimeMillis() method's variance can be up to 10 ms, sometimes the order of execution influences the measures, the JIT-Compile-Times and the GC). Putting up a microbenchmark that is not flawed can be a pretty daunting task. These could are pretty good primers on the topic: http://www.ibm.com/developerworks/java/library/j-jtp02225/index.html http://www.ibm.com/developerworks/library/j-jtp12214/ That doesn't keep me from using final on references (not methods/classes) wherever possible and also refactoring my code to use that keyword when it does not compromise readability too much. The reason is that it makes understanding code easier for me. Once you're used to seeing "final" everwhere, you'll especially note those places which are not marked finally; because they are the minority they stand out, they catch your attention. These are the variables - in the very sense of the word. The less variables you've got keep in mind, the easier it is to understand what code does. It has served me very well in the past 10 years and I do think it's worth the effort. You may argue that it is no good for methods which are basically just 3 lines long, but I'll do it there anyway: To avoid blurring the concept, keeping the habit, keeping the "not final means attention!" sense sharp. So I'd like to use "final" to express my intention in code very precisely, I'm not doing it for optimizing things. It's a shame that in Java not all references are implicitly final and only real variables get marked with "var" instead - that would serve the same purpose with less effort and less visual clutter. Also with putting final in front of all method parameterts, long lists of parameters begin to smell and cry for a refactoring earlier, which isn't really a bad thing in my opinion (depends on code-formatting though). Kind regards, Wanja -- ..Alesi's problem was that the back of the car was jumping up and down dangerously - and I can assure you from having been teammate to Jean Alesi and knowing what kind of cars that he can pull up with, when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer] --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---