Re: Opinions of advice to always define an empty noargs
constructor?
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---910079544-906766856-1251730305=:1212
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.1.10.0908311552071.1212@urchin.earth.li>
On Thu, 27 Aug 2009, David Karr wrote:
On Aug 27, 9:58?am, Tom Anderson <t...@urchin.earth.li> wrote:
On Thu, 27 Aug 2009, david.karr wrote:
I was recently reviewing some code that consistently defined empty and
redundant "noargs" constructors. ?I pointed this out (along with the
humorous method comment of "Default constructor"), ?but was told the
code was developed with the requirement of using the Checkstyle
plugin, which has an advice of always defining an empty noargs
constructor and not using the default constructor (assuming you didn't
need a noargs constructor that was non-empty).
I've never been that fond of advice that creates useless code that
takes up space better taken by real code, but I'm wondering what other
people's studied opinions are on this.
I'm with you - this is a dumb thing to do.
Mind you, i'm surprised that there are so many empty no-args constructors,
rather than constructors that actually do something. Could that be a code
smell in and of itself?
This is a typical pattern you see in dependency-injection
environments. Our dependency-injection framework
Aha, i've just made the connection to your other post. I take your point.
(not Spring, unfortunately)
Very unfortunately! Enjoying 9.1 yet?
I don't have any code to hand, but i don't think i've seen explicitified
default constructors in any Nucleus components written at my company.
Eric raised the point that making the constructor explicit gives you
somewhere to hang javadoc, but since this constructor will never be called
by a human programmer (it's purely there to support newInstance), that's a
non-issue here, i'd say. It can also be used as a place to document the
state of a fresh instance, but again, in this context, that's not terribly
relevant, because no human programmer gets to play with a fresh instance:
immediately after the newInstance, the framework will inject property
values from a configuration file. You do need to document what properties
need to be set in that file before an instance is useful, but i think that
belongs in the class comment. If there are any properties which have
default values set by initializer expressions or whatever (or even by an
explicitly nontrivial constructor), then i think i'd document those in the
getter methods for those properties, not the constructor or the class.
So still, no, don't write the default constructors out. You have enough
boilerplate to deal with without that!
tom
--
I drink quarts and cans and bottles and sixes; between the turntables
keep the vodka and the mixes. -- MCA
---910079544-906766856-1251730305=:1212--