[Gusdev-gusdev] Re: import statement policy

[Jonathan C. <cra...@pc...>]

Steve-

On Sat, 2 Aug 2003, Steve Fischer wrote:
> This file refers to a bunch of classes that are new to me, and, as i am 
> trying to understand what is going on, i have to go visiting.  But, each 
> time i do so, i have to wade through all those packages to try to figure 
> out where the class lives in order to visit it.  sometimes i can guess, 
> and sometimes i can't

What development environment are you using?  At least in emacs, you can 
use the standard etags package, or something fancier like JDE, both of 
which should allow you to find all possible definitions of an unqualified 
class name with a mouse click or two and a couple of keystrokes.  This 
should be as fast as, if not faster than, scrolling to the top of the file 
to find the relevant fully-qualified import statement, particularly when 
you add in the amortized cost of maintaining a correct minimal list of 
fully-qualified includes (preferably in lexically-sorted order -- see 
below).

Perhaps we should ask the following question: why does Java have import 
statements?  They are not necessary, in the sense that you can write every 
valid Java program without them, by using fully-qualified names throughout. 
I can think of only two reasons why import statements were added to the 
Java language:

 1. They save the programmer a lot of time (from typing long names).
 2. They provide a concise human-readable summary of the dependencies of 
    a class or interface.

This may be an oversimplification, but I believe that people who tend to 
care more about 1. will use ".*" more often in their import statements, 
and people who care more about 2. will tend to use ".*" less frequently.  
Of course my argument about 2. depends somewhat on whether people care 
more about summarizing package-level dependencies or class-level 
dependencies.  In some situations one might only care to know the 
package-level dependencies, in which case ".*" is sufficient.  If you want 
to be able to quickly assess both these things from a class that has a 
large number of import statements, it would seem wise to adopt 
the additional convention of sorting the import statements (so that it's 
easier for the eye to pick out the distinct packages involved.)

I don't really buy the argument that 2) is important enough to justify 
wasting a programmer's valuable time maintaining sorted lists of 
fully-qualified import statements.  There are programs that can convert 
Java code from one form (fully-qualified imports) to the other (.* imports) 
and back again; so if you inherit a large codebase with .* imports, you 
just have to run a program to convert it to whatever form you find easiest 
to understand.  Using a program to do this job, instead of a programmer, also 
has the advantage that it solves the maintenance problem; any class that 
isn't referenced won't have an import statement.  So I think my opinion is 
that ideally programmers should be allowed to use whatever style is easiest 
for them, but that before the code is checked into CVS, it should be run 
through a tool that expands all the import statements and eliminates the 
unneeded ones.

Jonathan