Imports: Explicit listings VS package wildcards

[Chris McMahon]

I'm currently deciding on whether our development team should explictly
list classes or use package wildcards for their imports. I've been
explicitly listing classes for years now, but the development team has
been using wildcards instead.

It seems to me that it is easier for people unfamiliar with your code to
understand where classes you're referencing are coming from by looking
at your imports when there are no wildcards. On the other hand, modern
IDEs do make looking up classes relatively easy. I have noticed that
JDKs and a lot of modern open source projects list imported classes
explicitly.

I don't want to be an unnecessary pain to the development team if there
are good reasons for going with wilcards, but my experience so far tells
me it is better to list things explicitly.

Any opinions on this?

 

[Raymond DeCampo]

I'm currently deciding on whether our development team should explictly
list classes or use package wildcards for their imports. I've been
explicitly listing classes for years now, but the development team has
been using wildcards instead.

It seems to me that it is easier for people unfamiliar with your code to
understand where classes you're referencing are coming from by looking
at your imports when there are no wildcards. On the other hand, modern
IDEs do make looking up classes relatively easy. I have noticed that
JDKs and a lot of modern open source projects list imported classes
explicitly.

I don't want to be an unnecessary pain to the development team if there
are good reasons for going with wilcards, but my experience so far tells
me it is better to list things explicitly.

Any opinions on this?

Using wildcards in imports can cause your code to fail to compile when
you upgrade the JDK or other libraries, if the upgrades include new
classes that conflict with existing class. Whether or not this small
risk is a big deal to you is another story.

Modern IDEs also make it easy to manage imports in either style.

HTH,
Ray

 

[Oscar kind]

I'm currently deciding on whether our development team should explictly
list classes or use package wildcards for their imports. I've been
explicitly listing classes for years now, but the development team has
been using wildcards instead.
[...]
I don't want to be an unnecessary pain to the development team if there
are good reasons for going with wilcards, but my experience so far tells
me it is better to list things explicitly.

Any opinions on this?

Personally, I prefer wildcards, because it looks better without code
folding (I dislike lots of what I see as non-code & non-comment). Also (as
already stated), IDE's can easily help in identifying the exact class.

On the other hand: if your code will be viewed with a web view of a SVN/CVS
repository, then explicit listings are better as there is no help in
identifying the fully qualified class name.

 

[Stefan Schulz]

I don't want to be an unnecessary pain to the development team if there
are good reasons for going with wilcards, but my experience so far tells
me it is better to list things explicitly.

Any opinions on this?

import java.util.*;
import java.awt.*;

class Foo {
private List X = null; // this does not compile
}

Need i say more?

 

[Chris Uppal]

I don't want to be an unnecessary pain to the development team if there
are good reasons for going with wilcards, but my experience so far tells
me it is better to list things explicitly.

The more I think about it, the less value I see in explicitly importing
classes.

If I see an 'import java.net.*' at the start of a file, then I know "OK, we're
doing networking here", similarly for java.awt, etc. If I see a long list of
imports then there's no way that I'm going to read through it, make a note of
each class used (perhaps write it on a PostIt note), and keep that list in mind
when I'm reading the code. All I'll do is scan down it, see that it uses a lot
of classes in java.net, and think "OK, we're doing networking here" -- just as
before.

Then when I'm reading the code, if I see a class with a familiar name, then I
/guess/ what it refers to from my background knowledge that we are doing
networking -- I most certainly do not refer to my pile of PostIts to decide
what class was named in the imports section.

Of course that only works for classes that I might be expected to be familiar
with, and that's my real point. If a class is named in the code that I can't
be expected to recognise from context, then it doesn't make any difference
whether it was imported explicitly or implicitly back at the beginning of the
file, it is still an unknown /at the point where I'm seeing the class name/.
So I now believe that such names should be fully-qualified at the point of use,
rather than relying on the obfuscating effect of import statements at all.

Put it this way, if a class is part of some context (such as network
programming) that the reader can be expected to be familiar with, then the
explicit import gains nothing (and perhaps costs more work, depending on
which IDE, if any, is used). If, on the other hand, the class is unknown or
unexpected in that context (say a java.awt.point2d in the middle of networking
code) then the name should be fully-qualified at the point of use. Imports (of
either style) are /only/ an abbreviation, and -- like most shortcuts -- they
can reduce code clarity if overused.

BTW, note how this ties in with the fairly well-regarded credo that
cross-package references should normally be to interfaces rather than classes.
The names of concrete classes should (mostly) be confined to their own package.
If such design guidelines are followed, then the type names used in the program
code will (mostly) be names of interfaces, and -- they being generic and few --
can be expected to be familiar. Hence it is (by my reasoning) preferable to
import them using wildcards. Such names of concrete classes as do occur will
either be (rare) references to foreign classes, or (common) references to
classes in the same package. The latter case needs no import statement at all,
the former -- /because/ it is rare -- can, and (IMO) should, be handled by
using fully-qualified names at the point of use.

-- chris

 

[.]

I'm currently deciding on whether our development team should explictly
list classes or use package wildcards for their imports. I've been
explicitly listing classes for years now, but the development team has
been using wildcards instead.

It seems to me that it is easier for people unfamiliar with your code to
understand where classes you're referencing are coming from by looking
at your imports when there are no wildcards. On the other hand, modern
IDEs do make looking up classes relatively easy. I have noticed that
JDKs and a lot of modern open source projects list imported classes
explicitly.

I don't want to be an unnecessary pain to the development team if there
are good reasons for going with wilcards, but my experience so far tells
me it is better to list things explicitly.

Any opinions on this?

I can think of one reason you want to explicitly list the class name
rather than use a wildcard, that is when there are two packages that
contain the same class.

There are actually three options:

1) Always use wildcards
2) Always use explicit names
3) Use wildcards unless you need explicit names

Option 1 is easier for the programmer creating some code. Option 2 helps
to avoid problems when two packages have the same class name but is more
work for the programmer. Option 3 works. I'd go with option 3. Actually,
most people go with option 1 until they are forced to option 3; many never
need option 3.

 

[.]

Using wildcards in imports can cause your code to fail to compile when
you upgrade the JDK or other libraries, if the upgrades include new
classes that conflict with existing class. Whether or not this small
risk is a big deal to you is another story.

I'm not sure if I follow this. If I try to imagine a scenario the only
thing I can see is if I have:

import some.standard.package.*; // needed for class Foo
import some.other.package.*; // needed for class Bar

then I upgrade my JDK and the new release contains the class
some.other.package.Foo. Therefore, previously this code compiled but with
the new JDK I get a conflict.

Is this what you are talking about?

 

[Raymond DeCampo]

I'm not sure if I follow this. If I try to imagine a scenario the only
thing I can see is if I have:

import some.standard.package.*; // needed for class Foo
import some.other.package.*; // needed for class Bar

then I upgrade my JDK and the new release contains the class
some.other.package.Foo. Therefore, previously this code compiled but with
the new JDK I get a conflict.

Is this what you are talking about?

Exactly.

Ray

 

[Wibble]

I can think of one reason you want to explicitly list the class name
rather than use a wildcard, that is when there are two packages that
contain the same class.

There are actually three options:

1) Always use wildcards
2) Always use explicit names
3) Use wildcards unless you need explicit names

Option 1 is easier for the programmer creating some code. Option 2 helps
to avoid problems when two packages have the same class name but is more
work for the programmer. Option 3 works. I'd go with option 3. Actually,
most people go with option 1 until they are forced to option 3; many never
need option 3.

Its just sloppy to use wildcards. I've spent too much time searching
through files to find where symbols are defined. IDE's help, but you
shouldn't be dependent on them. IDE's will also make it easier to put
the packages in. We've excluded wildcards in our coding standard and
nobody misses them.

 

[Dale King]

I'd say option 2 is also the best for anyone trying to read your code
(as Wibble alludes to below).

Its just sloppy to use wildcards. I've spent too much time searching
through files to find where symbols are defined. IDE's help, but you
shouldn't be dependent on them. IDE's will also make it easier to put
the packages in. We've excluded wildcards in our coding standard and
nobody misses them.

If you are using a decent IDE there should be absolutely no advantage to
option 1. I can't remember the last time I actually typed an import
statement myself. In Eclipse, I just type the first couple letters of
the class name, hit ctrl-space, select the correct class and it handles
the import statements for me. You can set it up to do your import
statements how you want so I see no reason to use option 1.

 

[Chris Smith]

The more I think about it, the less value I see in explicitly importing
classes.

I tend to agree. However, I never use wildcards anyway. The reason is
that any IDE worth its salt ought to add imports for you anyway rather
than making you scroll to the top of the file and add them yourself. I
haven't typed an import statement in a very long time. My IDE, Eclipse,
happens to add explicit imports for each class, and that's fine with me.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris McMahon]

I'll go with my original plan and insist on explicitly listing classes.
I was looking for a compelling reason to go against my view on this,
but didn't really get one IMO.

Thanks for all the responses.