Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Style Police (a rant) Date: Sat, 27 Aug 2011 09:58:43 +0200 Lines: 41 Message-ID: <9brmdkFqsmU1@mid.individual.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net JQNzDOe+ZGg9LuHNgXgHHwL/DXDG62qxB12gJzlAq0++BKnXk= Cancel-Lock: sha1:f/i6DUm3vj+w26cHU35vYBMuC78= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:7408 On 08/27/2011 02:56 AM, Eric Sosman wrote: > > In recent days I've encountered a tool called "Checkstyle," that > parses Java code and flags various departures from its baked-in rules. > Some of these are worthwhile: It will whine if you override equals() > without overriding hashCode(), it will shriek if a method's Javadoc > omits a @param or @throws, it will moan if a static final field isn't > ALL_CAPS, and so on. Some are less so: It insists that all method > parameters should be final, it forbids the ?: operator, it tut-tuts > at `x << 8' for using a "magic number." > > But the subject of this rant is its complaint that a class is "not > designed for extension." You write a perfectly ordinary class with > methods foo() and bar(), and Checkstyle throws up its hands and gibbers > that your class is "not designed for extension." Say, what? > > Well, it turns out that "not designed for extension" means that > your class has one or more methods that are not either final, abstract, > or empty. That's it, that's The Rule. ... > Enforcing good style is difficult. I wish the purveyors of the > enforcement tools would realize it's beyond their powers to do it well. I couldn't agree more, especially since I have suffered badly from the "method parameters must be final" style police of this tool (which has issues of its own) when a company bought my company and tried to introduce the checkstyle police on a ton of existing code. Luckily I could avoid being forced to convert _all_ method parameters in the code to the "new style" - and eventually working for the company altogether. And it's not only the authors of such tools. There are managers for whom it seems to be easier to enforce rules with tools like these than to judge the quality of their workforce themselves. I can accept that these programs are imperfect (and e.g. use them to deliver helpful hints), but people making these programs a bible are worse. Kind regards robert