Journal Articles
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:
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.
- 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>
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 ..