OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



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

[ Lists Home | Date Index | Thread Index ]
  • From: Barry Cornelius <Barry.Cornelius@durham.ac.uk>
  • To: David Megginson <david@megginson.com>
  • Date: Thu, 2 Mar 2000 18:21:47 +0000 (GMT)


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

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@durham.ac.uk

Version: 2.6.2i


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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS