Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: Eric Sosman <esosman@ieee-dot-org.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Style Police (a rant)
Date: Fri, 26 Aug 2011 20:56:40 -0400
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <j39fdc$1hi$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 27 Aug 2011 00:57:16 +0000 (UTC)
Injection-Info: mx04.eternal-september.org; posting-host="f8igmItKsWs6nM5YanFxAA"; logging-data="1586"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Z7rlby4adVdzjtA+MuRgn"
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0
Cancel-Lock: sha1:QGYncFRG3YRsTag/oXyQYWUh7bU=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:7405


     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.

     You can "design for extension" by having final methods, methods
that a subclass cannot override even if it needs to.

     You can "design for extension" by having abstract methods, methods
with no implementation that a subclass must implement on its own.

     Or you can "design for extension" by having methods that do
nothing at all.  (A peculiar measure of productivity, it seems to me.)

     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
you freeze your methods against overriding or ensure they're impotent.

    I wonder what this Checkstyle tool would think of the concrete,
non-final, non-empty equals(), hashCode(), clone(), toString(), and
finalize() methods of ... java.lang.Object, the one class *no* Java
program can avoid extending.  If java.lang.Object is "not designed for
extension," is there any hope left for the language?

     Enforcing good style is difficult.  I wish the purveyors of the
enforcement tools would realize it's beyond their powers to do it well.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid