Opinions of advice to always define an empty noargs constructor?

[david.karr]

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.

 

[Lew]

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.

You should follow the official style for you. Who made the writers of
Checkstyle the experts on your style?

If the default option in Checkstyle differs from yours, isn't there a
way to change Checksyle's options to fit your way?

There's really no way to give a firm rule on style issues, because,
well, they're issues of style.

FWIW, I consider requiring a no-arg constructor when it's the only one
to be silly.

 

[markspace]

code was developed with the requirement of using the Checkstyle
plugin, which has an advice of always defining an empty noargs

So redundant ctors were added because Checkstyle said to? If Checkstyle
told you to jump off a bridge, would you?

 

[Tom Anderson]

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?

tom

 

[markspace]

There is a more charitable interpretation. The Checkstyle configuration
in use, even if it is simply the default configuration, may be the
result of negotiations among the Powers That Be on the project,
representing a series of compromises that all of them can live with.

Well, the OP didn't give any justification for the no-arg ctors, just
"Checkstyle". And David Karr, the OP, didn't seem aware that it was a
required coding style mandated by his employer. He flagged the
redundant code as, well, redundant. It was his colleague who used the
Checkstyle defense.

So, does that really sound like a decision made by the Powers that Be?
Or is it one part of the organization trying to inflict their own little
code style on the rest?

The worst approach to coding standards is continuous change, in which
one can estimate when code was written by looking at the indentation
etc. It is better to stick to a set of coding standards once they have
been chosen, and not spend time continuously revisiting them.

This is an interesting observation. I'd add that an equally bad
practice is to allow each little unit in the organization its own little
code style, to the point where one can guess which team and even which
individual developer wrote each piece of code, by the code style used.

This sounds like what Karr's complaining about. I agree with him.

 

[markspace]

It is best if every public method and constructor has a proper Javadoc
comment (NOT "default constructor" !). To put a Javadoc comment on the
no-arg constructor, you have to write it out in the source code.

Ah, this is actually a good point, I hadn't thought of that. I think
you could use the class documentation itself in place of an explicit
no-arg ctor, but it does make sense to provide an entry in the Java docs.

reasons, I use the 'public' specifier in interface method declarations,
even if it is redundant.

This is actually something I avoid. It's clearly redundant, and to me
someone reading the code of an interface should know enough to
understand that. Likewise, I omit "static" from constant declarations
in an interface.

I do however add a comment "// package private" to any member which I
deliberately make package private.

 

[David Karr]

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 (not Spring,
unfortunately) doesn't support (I believe) constructor injection,
which isn't commonly used in Spring anyway.

 

[David Karr]

Well, the OP didn't give any justification for the no-arg ctors, just
"Checkstyle".  And David Karr, the OP, didn't seem aware that it was a
required coding style mandated by his employer.  He flagged the
redundant code as, well, redundant.  It was his colleague who used the
Checkstyle defense.

So, does that really sound like a decision made by the Powers that Be?
Or is it one part of the organization trying to inflict their own little
code style on the rest?

In a very large organization like the one I work in, it's not unusual
for different development groups, even closely related ones, to have
slightly different coding standards.

This is an interesting observation.  I'd add that an equally bad
practice is to allow each little unit in the organization its own little
code style, to the point where one can guess which team and even which
individual developer wrote each piece of code, by the code style used.

This sounds like what Karr's complaining about.  I agree with him.

What bothers me is when people implement consistency for its own sake,
without considering whether there's any value provided. When people
follow particular standards without having any idea why they're doing
it, outside of just being consistent, I'd consider that a problem.

I see no problem with coding standards evolving over time in an
organization. If the group comes to a realization that a particular
practice provides no value, is "being consistent" the only reason to
continue following that practice? That doesn't mean I would recommend
going back and changing all the existing code to match that standard.

The ultimate value that standards provide is code readability and
maintainability, not "consistency". When people become aware of that
truth, it's easy to see some situations where violation of the coding
standards can enhance readability and maintainability.

Concerning the various standards-compliance plugins, it's quite common
for development groups to just adopt the entire set of advisories the
plugin provides, without considering whether all of them in the set
are reasonable or not, and not even noting the fact that all of those
plugins have at least some configurability in removing certain checks
from the standard list.

 

[markspace]

In a very large organization like the one I work in, it's not unusual
for different development groups, even closely related ones, to have
slightly different coding standards.

Probably unavoidable. I think it's annoying, but then I've been the
recipient of top down code and documentation requirements for entire
departments with 200+ people. That's not really a great solution either.

What bothers me is when people implement consistency for its own sake,
without considering whether there's any value provided. When people
follow particular standards without having any idea why they're doing
it, outside of just being consistent, I'd consider that a problem.

That was the gist of my first reply. If Checkstyle told you to jump off
a bridge, would you? Give me a reason other than Checkstyle told you
to. (Not you, personally, of course, just "you plural," i.e., folks in
general.)

I see no problem with coding standards evolving over time in an
organization. If the group comes to a realization that a particular
practice provides no value, is "being consistent" the only reason to
continue following that practice? That doesn't mean I would recommend
going back and changing all the existing code to match that standard.

Actually I agree, but I've also seen a lot of "developer drift" where
things are made different just for the immediate convenience of a team
or even for no reason whatsoever. The maintenance hassles pile up and
quickly overwhelm the staffing allowance.

 

[Dave Searles]

That was the gist of my first reply. If Checkstyle told you to jump off
a bridge, would you? Give me a reason other than Checkstyle told you
to. (Not you, personally, of course, just "you plural," i.e., folks in
general.)

If your GPS told you to jump off a bridge, would you?

Scarily, the answer from some people appears to be "yes" in that
particular instance.

 

[Lew]

Is the no-args constructor useful? That is, does it create an
object instance that is useful? If so, the constructor should probably
exist. If not, the constructor should not exist, unless maybe the class
is abstract.

The question isn't whether the constructor exists, but whether it is explicit
in the source.

The question of which constructors to provide is just like the
question of which methods to provide: You want constructors that produce
useful objects and that are convenient for the callers. If a no-args
constructor is convenient and generates a useful object, I see nothing
wrong with writing one explicitly -- if nothing else, it gives you a
place to hang the Javadoc.

And the Javadoc would look something like this:

/** Constructs an instance.
*/
public Foo()
{
}

What's useless there is the Javadoc.

 

[Roedy Green]

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.

One argument in favour of putting no arg constructors in is you break
existing code that subclasses you class if you add a specific
constructor without the no-arg constructor. If you put the no-arg
constructor in from the start, than would not happen. But then
sometimes you don't want people using the no-arg constructor. You can
indicate that by leaving it out, and providing a specific constructor
or by making it private.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"There is an evil which ought to be guarded against, in the indefinite accumulation of property,
from the capacity of holding it in perpetuity by... corporations.
The power of all corporations aught to be limited in this respect.
The growing wealth acquired by them never fails to be a source of abuses."
~ James Madison (born: 1751-03-16 died: 1836-06-28 at age: 85)

 

[Dave Searles]

The question isn't whether the constructor exists, but whether it is
explicit in the source.


And the Javadoc would look something like this:

/** Constructs an instance.
*/
public Foo()
{
}

What's useless there is the Javadoc.

That's an argument against writing bad Javadoc, not an argument against
explicit empty constructors.

A more useful example would be if the Javadoc documented something
important about the initial state of the object. (This initial state
could be nontrivial; the constructor body might be empty because field
initializers are able to do all the work.)

 

[Lew]

That's an argument against writing bad Javadoc, not an argument against
explicit empty constructors.

A more useful example would be if the Javadoc documented something
important about the initial state of the object. (This initial state
could be nontrivial; the constructor body might be empty because field
initializers are able to do all the work.)

Fair enough. What would you write?

 

[Arne Vajhøj]

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.

Since I am as lazy as everyone else I tend to omit making
the default constructor explicit.

But I can see the point in the rule. For reasons very similar
to Patricias.

It cost very little to add. And it does make the code more explicit,
which is a good thing.

And if there ever were a reason to add a constructor with an argument
then that would make it easy for an unexperienced programmer to
break the build by forgetting to add the no arg constructor at that
time.

It is an argument very similar to the argument for using { } even
with single line blocks.

Arne

 

[Arne Vajhøj]

What bothers me is when people implement consistency for its own sake,
without considering whether there's any value provided. When people
follow particular standards without having any idea why they're doing
it, outside of just being consistent, I'd consider that a problem.

I see no problem with coding standards evolving over time in an
organization. If the group comes to a realization that a particular
practice provides no value, is "being consistent" the only reason to
continue following that practice? That doesn't mean I would recommend
going back and changing all the existing code to match that standard.

The ultimate value that standards provide is code readability and
maintainability, not "consistency". When people become aware of that
truth, it's easy to see some situations where violation of the coding
standards can enhance readability and maintainability.

Consistency is critical for readability so it always has value.

Arne

 

[Lew]

Since I am as lazy as everyone else I tend to omit making
the default constructor explicit.

But I can see the point in the rule. For reasons very similar
to Patricias.

It cost very little to add. And it does make the code more explicit,
which is a good thing.

And if there ever were a reason to add a constructor with an argument
then that would make it easy for an unexperienced programmer to
break the build by forgetting to add the no arg constructor at that
time.

It is an argument very similar to the argument for using { } even
with single line blocks.

But one should not have conniption fits over omission of a no-arg constructor
in favor of the default as one should have over omitted curly braces.

 

[Arne Vajhøj]

But one should not have conniption fits over omission of a no-arg
constructor in favor of the default as one should have over omitted
curly braces.

Same type of problem. Why not same handling?

Arne

 

[Lew]

Same type of problem. Why not same handling?

Purely social reasons. The use of the default constructor is very ingrained
in the Java language and the programming culture. It's like the
opening-brace-placement strategy - there are two very well-known idioms and
either should be acceptable to any reasonable reviewer. Same with presence of
an empty no-arg constructor. While it makes sense that an explicit
constructor is more satisfactory from an anal standpoint, it also makes sense
that an empty constructor that does not contribute to other code already
present is mere fluff and completely extraneous. Either should be acceptable.

 

[Tom Anderson]

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