[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Style of import declarations (Was: org.xml.sax.ContentHandler conflicts

• From: Barry Cornelius <Barry.Cornelius@d...>
• To: David Megginson <david@m...>
• Date: Thu, 2 Mar 2000 18:21:47 +0000 (GMT)

-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 2 Mar 2000, David Megginson wrote:
> Not completely absolved, granted, but if programmers use java.net.*
> they're really setting themselves up for this.  What happens if the
> next Java release also contains a java.net.InputSource class (for
> example), or a java.net.Locator class?  Will we have to put out
> revised a SAX3/Java just to change those names as well?

I know you guys really do not want a thread on programming style, but I
have now seen three of you (Sabin, Megginson, Harold) exchange views on
this, and I cannot hold back any longer.  So here they are. 

I say to my students: 
> The * form is a lazy cop-out.  In its extreme form, you just put a list
> like this at the start of each file: 
>   import java.awt.*;
>   import java.io.*;
>   import java.net.*;
>   import java.sql.*;
>   import java.util.*;
>   import javax.swing.*;
> even if you don't use any classes from these packages, and so you need
> not be bothered with import declarations.  This is a bad programming
> practice: the list of import declarations is a good way of documenting
> from which package a class is being obtained."

If you adopt the * form, you give the compiler permission to go and get
anything it likes, and most of the time you get what you want.  If you
adopt this style, then after a while you may wonder why the language
obliges you to write all this lot.  What a silly language: why can't the
default be to search all the Core APIs and only require import
declarations in order to resolve ambiguities or to get things from other
APIs. 

Incidentally, the style I teach is illustrated by:
   import java.awt.event. ActionEvent;
   import java.awt.event. ActionListener;
   import java.awt.       BorderLayout;
   import javax.swing.    Box;
   import javax.swing.    BoxLayout;
   import java.awt.       Container;
   import java.util.      Date;
   import java.util.      HashSet;
   import javax.swing.    JFrame;
   import javax.swing.    JTextField;
   import java.util.      Set;

The lines are ordered by the names of the classes, and there is a single
space before the class name that has the longest package name.  
My claim is that this style is helpful to the reader: he/she is able to
determine easily in which package a class is located.  Why should a
maintainer have to know where every class is located? 

- --
Barry Cornelius                      Telephone: (0191 or +44 191) 374 4717
User Services, Information Technology Service,            Office: 374 2892   
Science Site, University of Durham, Durham, DH1 3LE, UK      Fax: 374 7759
http://www.dur.ac.uk/~dcl0bjc          mailto:Barry.Cornelius@d...

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i

iQCVAwUBOL6xP6GgSldA40uVAQFg7wP9HAEzcwdwj92nY3lixd0GwPYY8ls4wWyr
qXIan3gx8NDu30TiD+jd6ACJnXvFS7rG5L2LRFlunvdDgVKJiyyYTgSlrQjARKJX
UPt+ItVJFGoWWTdAIxWlwyaDlBgVVQEJig4CBGVvgheO3B38zfHck2rQhdzZtCzW
SSAsMwmOHu0=
=4Sye
-----END PGP SIGNATURE-----


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************

• References:
  • Re: org.xml.sax.ContentHandler conflicts with java.net.ContentHan dler
    • From: David Megginson <david@m...>

• Prev by Date: Re: XPath -> SQL
• Next by Date: Re: 25 Feb Structures Comments
• Previous by thread: Re: org.xml.sax.ContentHandler conflicts with java.net.ContentHan dler
• Next by thread: Re: org.xml.sax.ContentHandler conflicts with java.net.ContentHandler
• Index(es):
  • Date
  • Thread