Journal Articles

CVu Journal Vol 11, #1 - Nov 1998 + Programming Topics
Browse in : All > Journals > CVu > 111 (19)
All > Topics > Programming (877)
Any of these categories - All of these categories

Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.

Title: Java Idioms

Author: Administrator

Date: 03 November 1998 13:15:28 +00:00 or Tue, 03 November 1998 13:15:28 +00:00

Summary: 

Body: 

Series Introduction

This series of articles will attempt to present "standard" Java idioms. It will try to present "best of practice" approaches. As these are pretty tall claims it would be really useful to receive feedback either direct email or via C Vu. Any suggestions for future articles would be greatly appreciated.

The articles will be presented in a standard format:

Name:

idiom name

Rationale:

reason for idiom

Advantages:

advantages of the idiom

Disadvantages:

disadvantages of the idiom

Description:

full description of the idiom including examples

Intended articles include:

  • javadoc comments

  • code layout

  • exception handling

  • field/method names

  • variable names

  • main in every class

  • modifier order

  • finalizers

Please note that examples will generally be very contrived for the purpose of being illustrative rather than demonstrating good design ☺

The articles will generally be applicable to all Java versions. I'll try to point out any pertinent differences when necessary.

Java Idioms : javadoc comments

Name:

javadoc comments

Rationale:

self documenting code. Permits the low level interface documentation to appear inline with the code. This prevents unnecessary duplication (i.e. separate document duplicating code comments).

Advantages:

low-level documentation for interface specifications should always be up to date.

Disadvantages:

slightly more time to produce the code (the combined code and interface specification time should be shorter). Must keep comments up to date with the source (maintenance issue).

Description:

There are certain points in a Java source file where javadoc comments may sensibly be placed. These are:

  • before a class or interface specification

  • before a field specification

  • before a method specification

Note that one can profitably comment all forms of field or method specification (public, protected, private and package visibility). Running javadoc with an appropriate option will produce increasingly more detailed HTML documents. By default javadoc will generate documentation for the public and protected fields/methods.

Tags

The following table lists the javadoc tags and their possible placements:

<colgroup> <col width="25%"> <col width="25%"> <col width="25%"> <col width="25%"></colgroup> <thead> </thead> <tbody> </tbody>
class/interface field method
@author *
@version *
@see * * *
@param *
@return *
@exception *
@since * *
@deprecated * *

Note that @since and @deprecated were introduced in JDK1.1.

The first period terminated sentence should be a short description of the class/interface, field or method. Watch out when including a decimal number! This will be used to generated a summary in the HTML documentation.

For trivial methods the short description along with a possible more complete description may be sufficient. This is especially true if the meanings of some parameters are obvious by their name or even by the method name. In non-trivial methods appropriate @param and @return (if non-void) should appear. Also if any exceptions are thrown then they should be documented with an @exception. One should use the fully qualified class name for the exception to permit the cross-reference documentation to be correctly generated.

Although it is unusual to include unchecked exceptions (e.g. those that extend java.lang.RuntimeException) in a method's throws clause it is good practice for the exceptions to be documented. For a good example of this see java.lang.String#charAt.

The idiom here is that classes, interfaces, fields and methods should be sensibly documented. Once one gets into the habit of typing in javadoc comments as one types the code it becomes second nature. Failure to do this loses out on one of Java's real strengths. An important point to note is that to be really useful the comments must be kept up to date.

Example

In the Point example the constructor has commented the parameters. It wasn't really necessary as the constructor is trivial. In fact in setX commenting the parameter would be overkill. The @return in toString is for the benefit of the example.

Note that one can utilise the versioning from the source control system to give a possible entry for the @version tag.

/*
 *  Copyright  (c)  1998  Mark  Kuschnir
 */
package  com.xyz.graphics;
/**
  *  XY  coordinates  of  a  point  in  a  graphical  
  *  coordinate  system.
  *  Only  permit  points  in  the  positive  quadrant:  
  *    x  >=  0  and  y  >=  0.
  *  @author  Mark  Kuschnir
  *  @version  $Revision:  1.1$
  */
  
public  class  Point
{
        /**  X  coordinate.  */        
        private  double  x;
        /**  Y  coordinate.  */
        private  double  y;
        /**
          *  Construct  a  Point  object.
          *  @param  x  X  coordinate
          *  @param  y  Y  coordinate
          *  @exception  java.lang.IllegalArgumentException  
             if  x  <  0  or  y  <  0
          */
          public  Point(double  x,  double  y)
          {
                if  (x  <  0  ||  y  <  0)
                  throw  new  IllegalArgumentException
                              (x+"  <  0  ||  "+y+"  <  0");
                this.x  =  x;
                this.y  =  y;
          }
         /**
          *  Get  the  X  coordinate.
          */          
        public  double  getX()
        {
                return  (x);
        }        
        /**
          *  Set  the  X  coordinate.
          */          
        public  void  setX(double  x)
        {
                this.x  =  x;
        }        
        //  getY  +  setY  methods
         /**
          *  Return  string  representation  of  the  point.
          *  @return  string  representation
          */
        public  String  toString()
        {
              return ("("+x+","+y+")");
        }
    /**
     * Test the class.
     */     
    public static void main(String[] args)
    {
      try
      {
        Point p = new Point(1,2);
        System.out.println("point = "+p);
        p = new Point(-1,-2);
      }
      catch (Exception e)
      {
        e.printStackTrace();
      }
    }
}

Notes: 

More fields may be available via dynamicdata ..