documentation/specification/coding_standards.txt

Coding Standards
================

tdb1, 28/11/20000


Document description
====================

The purpose of this document is to provide a defined
standard to which all code will conform. This will ensure
consistency across all files, and allow all members of the
team to easily follow the different pieces written by other
members.


Contents
========

 - Foreword
 
 - Structure & Layout
 
   - Identifiers
   - Final Variables
   - Indentation and Layout
   - Bracketing
   - Exceptions
   - Access Control
   - Imports
   - Overall Class Layout
 
 - Naming Conventions
 
 - Commenting & Documentation
 
   - Class and Interfaces
   - Methods
   - Attributes and Variables
   - General Commenting
 
 - General Recommendations
 
   - Threading
   - Class Design
   - Platform


Foreword
========

In constructing this document I have heavily used content
found in the following documents. I have tried to use these
documents to give our Coding Standard a solid foundation,
without doing a lot of unnecessary work that has already
been done by these authors.

The majority of this document is taken from the book by
David Barnes, with the other two just being used for small
parts which David hasn't covered in as much detail.

Java Stylistic Conventions, by David Barnes
  http://www.cs.ukc.ac.uk/people/staff/djb/Book/style.html
Draft Java Coding Standard, by Doug Lea
  http://g.oswego.edu/dl/html/javaCodingStd.html
Netscape's Java Coding Standards Guide
  http://developer.netscape.com/docs  ...
                          ...  /technote/java/codestyle.html


Structure & Layout
==================

Identifiers
-----------

Identifiers can come down to simple imagination, and there
isn't a right or wrong way of doing it. The only restriction
is that they should be descriptive and of a reasonable
length. A variable name should have a single use and a name
fitting to this use, rather than using a single
non-descriptive name for multiple purposes.

A common convention is that names of methods, attributes,
and variables should begin with an initial lower-case letter
and have a single upper-case letter at the start of each new
word within the name. Class names should begin with an
uppercase letter and follow the same rule for the start of
each new word. Examples of these could be:

  myVariable
  aClassAttribute

  aUsefulMethod()

  CleverClassName

Accessor and Mutators should have names based on the
attribute to which they provide access. They should begin
with the prefix get or set followed by the name of the
attribute beginning with a capital letter. For example the
variable item would have the following accessor and mutator:

  getItem()
  setItem()

Variable names with a single character, such as x, should be
avoided as they convey little about their use. The only
exception to this rule is when it is used as a loop-control
variable in a for-loop. In this instance the variable serves
only as a counter, and this is obvious from it's use.

Method variables are those used within a method and should
be used in preference to an attribute if their use is to be
short. They should be defined as close to their use as
possible to make code easier to follow. Use should be made
of the fact that variables defined within nested blocks are
only visible within the block of code, and thus is only
visible to it's related code.

Final Variables
---------------

It is important to avoid the use of magic numbers within the
code. The main reason for this is that it can be hard to
identify which numbers should be changed if the use of the
program needs to be altered. Instead a final variable should
be defined in the program:

  private final int ST = 2;
  private final int E = 3;
  private final int S = 1;

The only time when magic numbers are acceptable is when they
are used as a variable initialiser or as a simple step.
Sometimes final variables are needed by more than one class,
in which case they should be defined as public static final
instead. These types of variables with public visibility
should be placed at the start of the class definition

Final variables should also have all upper-case names, thus
making them clearly identifiable over class attributes. The
use of the final word will also dictate that they cannot be
changed, so accessor's and mutator's are not necessary.

Indentation and Layout
----------------------

Lines should be kept to a sensible length to make the code
easier to read and print. Lines should be broken at a
sensible point and indented further than the current level
of identation. If space permits they should be lined up as
appropriate with the previous line:

  private static final byte[] packet = { Datatypes.FLAG,
                                         Datatypes.TERM,
                                         Datatypes.FLAG,
                                       };

Indentation should be four spaces for each level, and single
blank lines should be used to separate methods and to
emphasize blocks of code, as in this example:

  class MyExample {
     
      public int returnValue(int x){
          return x;
      }
  
  }

Methods should be defined first in a class, preferably in
order of visibility - public methods first, private ones
after. Attributes should be defined after methods for the
class, exception for public final variables which should be
defined first. This will be discussed further in Overall
Class Layout later on in this document.

Bracketing
----------

Brackets are very common in Java code and can be used
sensibly to clearly show the blocks of code they
encapsulate. An opening curly bracket that follows a class
header should be indented by a single space, but those used
after a method header should not. Closing curly brackets
should be placed on the line after the last line of the code
they enclose, at the same level of indentation as the start
of the header on which the block begins:

  class MyExample {
      public void method(){
          . . .
      }
  }

Curly brackets should always be used for if-, while- and
for-, even when not strictly needed - such as when the body
only contains a single statement. This is the correct way to
do it:

  if(x > largest){
      largest = x;
  }

Sometimes statements within normal brackets need to be
broken across several lines. This break should occur after
an operator and the next line should be indented further
than the code which will follow in the body.

Exceptions
----------

Exceptions should be used where necessary, and these should
almost always be checked exceptions. Instead of throwing the
basic Exception classes, sub-classes should be made with
more meaningful names, although they need not provide any
further functionality. Appropriate catch statements should
be put in place to allow the program to recover if need be.

Access Control
--------------

The following rules should be adhered to, ensuring that
access control is correctly implemented and used.

  - Attributes of an object should be declared as private,
    rather than public, package or protected. The only 
    exception is in the use of static final variables which 
    cannot be changed anyway.
    
  - Accessors may be used to grant access to attributes of a
    primitive type, although much more care must be taken 
    when returning references to attributes of object types 
    since this could lead to possible bypassing of any 
    mutators.
    
  - Mutators should be protected unless they specifically 
    need to be public. A mutator can ensure that values are 
    checked before being put in to the private attribute.
    
  - Methods commonly have public access, although private
    access should be considered if the method is to be used 
    only by the class in which it is placed.
    
  - Package visibility should also be considered if the use 
    of packages is implemented. Again, each method's use 
    should be considered carefully, and an appropriate 
    access control method chosen.
    
  - Protected visibility is unlikely to be used as sub-
    classing any of the classes is unlikely, although if
    such a situation should arise it should be carefully
    considered.

When considering what type of access control to use it is
best to be more restrictive than lenient. If a method's
visibility is too restrictive then it will be identified
more quickly than if the reverse were to happen.

Imports
-------

The use if the * form of import should be avoided. Each
class should be specifically imported as required, and any
unused imports should be removed if they are no longer
needed. This makes it clear as to exactly what the class is
using.


Overall Class Layout
--------------------

The overall layout of a class is important, especially when
it comes to reviewing the code at a later stage. Here I will
outline the order in which methods and attributes should
appear in a class. This psuedo class shows where everything
should appear, including imports and package declarations.
Commenting will be dealt with in a further section.

  // package declaration
  package server
  // imports
  import java.util.LinkedList
  import java.io.InputStream
  
  class MyDummyClass {
  
      // attributes such as "magic numbers" should be first
      public static final int S = 1;
      public static final int E = 3;
  
      // no-args constructor first
      public MyDummyClass(){
          . . .
      }
  
      // further constructors follow
      public MyDummyClass(int x){
          . . .
      }
  
      // public methods
      public void myMethod(){
          . . .
      }
  
      // private methods
      private void anotherMethod(){
          . . .
      }
  
      // accessors & mutators
      public int getMyVar(){
          . . .
      }
  
      // private attributes
      private int myVar = 5;
  }

This layout should be followed in every source file
generated. The reason for this structure is that reading
downwards you reach the most used methods and attributes
first. The exception are the public static final attributes
which are put first to allow them to easily be identified
and changed at a later date.

Naming Conventions
------------------

Although this section has been covered throughout the last
section, I think it is key that the various naming
conventions be clearly identified here. Examples are given
for each convention.

  - Packages
      eg. demo.package
      Package names should all be in lower case.
  
  - Files
      eg. ClassName.java
      The Java convention is that files have the same name 
      as the class they contain, and the compiler enforces 
      this.
  
  - Classes
      eg. ClassName
      Class names should begin with a capital letter and 
      each new word within the name should begin with a 
      capital letter.

  - Exception Classes
      eg. ClassNameException
      Exception classes should follow the same rule as 
      normal classes, but should end with the word 
      Exception.

  - Constants or "magic numbers" (public)
      eg. MY_STATIC_VARIABLE
      These public static variables should always be in
      upper-case. An underscore could be used if required to 
      make the name more readable.

  - Methods
      eg. methodName()
      Methods should begin with a lower case letter and each 
      new word within the name should begin with a capital 
      letter.

  - Variables and Attributes
      eg. variableName
      Both variables and attributes should being with a 
      lower case letter and each new word within the name 
      should begin with a capital letter - exactly the same 
      as methods.

  - Accessors
      eg. getVariable()
      Accessors should follow the same rules as a normal 
      method, but should be named after the variable which 
      they provide access to.

  - Mutators
      eg. setVariable(...)
      Mutators should follow the same rules as a normal 
      method, but should be named after the variable to 
      which they control access.


Commenting & Documentation
==========================

All programs should be properly and thoroughly documented.
The javadoc tool provides a convention for documenting code
and facilitates the automatic generation of program
documentation.

Classes and Interfaces
----------------------

Each class should have a javadoc comment block at the start
of the code. This block of comment should be placed in the
standard javadoc style /** .. **/ immediately preceding the
class header. Package declarations and imports will appear
before this initial documentation. Within this section the
following items should be included:

  - Class Name
  - Description of the class and it's use
  - Revision History
  - Author(s) - javadoc tag
  - Version Number - javadoc tag

It is important to note that as well as the code being read
by hand, these comments will also be used to generate
information about the class on a webpage using javadoc.
Bearing this in mind it may be necessary to use HTML tags to
layout the comments, although these should be neatly done so
as not to make the comments unreadable in the source code.

Various javadoc tags should be used to give specific
information to the javadoc engine. These should be placed on
a separate line.

  - @author <author name>
    The name of the author, preferably with e-mail address.
    
  - @version <version number>
    The version number of the code, with date.

This is an example of a class header, which contains all of
the above items.

  /**
   * MyClass <br>
   *
   * This class is merely for illustrative purposes. <br>
   *
   * Revision History:<br>
   * 1.1 - Added javadoc headers <br>
   * 1.0 - Original release<br>
   *
   * @author T.D.Bishop
   * @version 1.1, 19/04/2000
   */
  public class MyClass {
      . . .
  }

Methods
-------

Methods should contain a similar javadoc comment to classes,
which should be places between /** .. **/ marks immediately
preceding the method header. It may not be necessary to do
this for all methods, but constructors and major methods
certainly should have them, whilst accessors and mutators
can have a more cut down version. The following items should
be included:

  - Purpose of method
  - Argument descriptions
  - Result descriptions
  - Exceptions thrown

There are also javadoc tags that can be used specifically
for method comments. In a similar way to class comments each
begins with an @ and should be placed on a line of it's own.

  - @param <param name> <param description>
    Should be specified for each parameter that a method 
    takes, with it's name and purpose.
    
  - @return <description>
    Describes the result returned by the method.
    
  - @throws <exception name> <reason for being thrown>
    Gives the name of any exceptions that may be thrown, and
    why.

Here is an example of a method header, showing the above in
use.

  /**
   * This method has no use, and it just illustrative. <br>
   * Although it does suggest adding the two parameters
   * together ! <br>
   *
   * @param first The first number to be added
   * @param second The second number to be added
   * @return The sum of the two parameters
   * @throws BadException if something goes very wrong !
   */
  public int sumNumbers(int first, int second) throws
  BadException{
      . . .
  }

Attributes and Variables
------------------------

Attributes and variables require far less commenting than
classes and methods. They should simply contain a brief
description of what they are used for, and could possibly
refer to any accessors or mutators that allow access to
them. Attributes that are public static final should have a
bit more detailed information as other classes may wish to
use them. Here is a basic example:

  /**
   * This attribute represents the byte value used to start
   * a packet.
   */
  public static final int ST = 2;


General Commenting
------------------

It is often necessary to add comments within the body of a
method. It is preferable to comment in blocks, rather than
individually on each line. Likewise it is not necessary to
comment code that is obvious in it's purpose. Both single
line comments (using //) and multi-line comments (using /*
.. */) are acceptable. This is an example of the layout of
the two methods:

  int index = 1; // index of starting point
  
  /* This is a mult-line
   * comment, and spans
   * several lines !
   */


General Recommendations
=======================

Threading
---------

Threading is a complicated issue, so I will only briefly
mention it. The main issue is using the synchronized
modifier to prevent deadlock over the system when accessing
shared objects. It is important not to overuse this, as it
can cause unnecessary deadlock. Use it only when there is a
clear need to do so.

Class Design
------------

Class design should be done in a way that reduces coupling
as far as possible. Simply dividing the overall system into
clear defined parts is a good way to start this.

Platform
--------

This document refers to the Java 2 platform (or JDK 1.2).
Everything mentioned in this document is based upon this
platform and may therefore be out of date in future versions
of the Java platform.

Revision:	1.1
Committed:	Tue Nov 28 00:14:21 2000 UTC (24 years ago) by tdb
Content type:	text/plain
Branch:	MAIN
CVS Tags:	PROJECT_COMPLETION
Log Message:	Basic draft of the coding standards. DOC -> TXT from a previous document.
#	User	Rev	Content
1	tdb	1.1	Coding Standards
2			================
3
4			tdb1, 28/11/20000
5
6
7			Document description
8			====================
9
10			The purpose of this document is to provide a defined
11			standard to which all code will conform. This will ensure
12			consistency across all files, and allow all members of the
13			team to easily follow the different pieces written by other
14			members.
15
16
17			Contents
18			========
19
20			- Foreword
21
22			- Structure & Layout
23
24			- Identifiers
25			- Final Variables
26			- Indentation and Layout
27			- Bracketing
28			- Exceptions
29			- Access Control
30			- Imports
31			- Overall Class Layout
32
33			- Naming Conventions
34
35			- Commenting & Documentation
36
37			- Class and Interfaces
38			- Methods
39			- Attributes and Variables
40			- General Commenting
41
42			- General Recommendations
43
44			- Threading
45			- Class Design
46			- Platform
47
48
49			Foreword
50			========
51
52			In constructing this document I have heavily used content
53			found in the following documents. I have tried to use these
54			documents to give our Coding Standard a solid foundation,
55			without doing a lot of unnecessary work that has already
56			been done by these authors.
57
58			The majority of this document is taken from the book by
59			David Barnes, with the other two just being used for small
60			parts which David hasn't covered in as much detail.
61
62			Java Stylistic Conventions, by David Barnes
63			http://www.cs.ukc.ac.uk/people/staff/djb/Book/style.html
64			Draft Java Coding Standard, by Doug Lea
65			http://g.oswego.edu/dl/html/javaCodingStd.html
66			Netscape's Java Coding Standards Guide
67			http://developer.netscape.com/docs ...
68			... /technote/java/codestyle.html
69
70
71			Structure & Layout
72			==================
73
74			Identifiers
75			-----------
76
77			Identifiers can come down to simple imagination, and there
78			isn't a right or wrong way of doing it. The only restriction
79			is that they should be descriptive and of a reasonable
80			length. A variable name should have a single use and a name
81			fitting to this use, rather than using a single
82			non-descriptive name for multiple purposes.
83
84			A common convention is that names of methods, attributes,
85			and variables should begin with an initial lower-case letter
86			and have a single upper-case letter at the start of each new
87			word within the name. Class names should begin with an
88			uppercase letter and follow the same rule for the start of
89			each new word. Examples of these could be:
90
91			myVariable
92			aClassAttribute
93
94			aUsefulMethod()
95
96			CleverClassName
97
98			Accessor and Mutators should have names based on the
99			attribute to which they provide access. They should begin
100			with the prefix get or set followed by the name of the
101			attribute beginning with a capital letter. For example the
102			variable item would have the following accessor and mutator:
103
104			getItem()
105			setItem()
106
107			Variable names with a single character, such as x, should be
108			avoided as they convey little about their use. The only
109			exception to this rule is when it is used as a loop-control
110			variable in a for-loop. In this instance the variable serves
111			only as a counter, and this is obvious from it's use.
112
113			Method variables are those used within a method and should
114			be used in preference to an attribute if their use is to be
115			short. They should be defined as close to their use as
116			possible to make code easier to follow. Use should be made
117			of the fact that variables defined within nested blocks are
118			only visible within the block of code, and thus is only
119			visible to it's related code.
120
121			Final Variables
122			---------------
123
124			It is important to avoid the use of magic numbers within the
125			code. The main reason for this is that it can be hard to
126			identify which numbers should be changed if the use of the
127			program needs to be altered. Instead a final variable should
128			be defined in the program:
129
130			private final int ST = 2;
131			private final int E = 3;
132			private final int S = 1;
133
134			The only time when magic numbers are acceptable is when they
135			are used as a variable initialiser or as a simple step.
136			Sometimes final variables are needed by more than one class,
137			in which case they should be defined as public static final
138			instead. These types of variables with public visibility
139			should be placed at the start of the class definition
140
141			Final variables should also have all upper-case names, thus
142			making them clearly identifiable over class attributes. The
143			use of the final word will also dictate that they cannot be
144			changed, so accessor's and mutator's are not necessary.
145
146			Indentation and Layout
147			----------------------
148
149			Lines should be kept to a sensible length to make the code
150			easier to read and print. Lines should be broken at a
151			sensible point and indented further than the current level
152			of identation. If space permits they should be lined up as
153			appropriate with the previous line:
154
155			private static final byte[] packet = { Datatypes.FLAG,
156			Datatypes.TERM,
157			Datatypes.FLAG,
158			};
159
160			Indentation should be four spaces for each level, and single
161			blank lines should be used to separate methods and to
162			emphasize blocks of code, as in this example:
163
164			class MyExample {
165
166			public int returnValue(int x){
167			return x;
168			}
169
170			}
171
172			Methods should be defined first in a class, preferably in
173			order of visibility - public methods first, private ones
174			after. Attributes should be defined after methods for the
175			class, exception for public final variables which should be
176			defined first. This will be discussed further in Overall
177			Class Layout later on in this document.
178
179			Bracketing
180			----------
181
182			Brackets are very common in Java code and can be used
183			sensibly to clearly show the blocks of code they
184			encapsulate. An opening curly bracket that follows a class
185			header should be indented by a single space, but those used
186			after a method header should not. Closing curly brackets
187			should be placed on the line after the last line of the code
188			they enclose, at the same level of indentation as the start
189			of the header on which the block begins:
190
191			class MyExample {
192			public void method(){
193			. . .
194			}
195			}
196
197			Curly brackets should always be used for if-, while- and
198			for-, even when not strictly needed - such as when the body
199			only contains a single statement. This is the correct way to
200			do it:
201
202			if(x > largest){
203			largest = x;
204			}
205
206			Sometimes statements within normal brackets need to be
207			broken across several lines. This break should occur after
208			an operator and the next line should be indented further
209			than the code which will follow in the body.
210
211			Exceptions
212			----------
213
214			Exceptions should be used where necessary, and these should
215			almost always be checked exceptions. Instead of throwing the
216			basic Exception classes, sub-classes should be made with
217			more meaningful names, although they need not provide any
218			further functionality. Appropriate catch statements should
219			be put in place to allow the program to recover if need be.
220
221			Access Control
222			--------------
223
224			The following rules should be adhered to, ensuring that
225			access control is correctly implemented and used.
226
227			- Attributes of an object should be declared as private,
228			rather than public, package or protected. The only
229			exception is in the use of static final variables which
230			cannot be changed anyway.
231
232			- Accessors may be used to grant access to attributes of a
233			primitive type, although much more care must be taken
234			when returning references to attributes of object types
235			since this could lead to possible bypassing of any
236			mutators.
237
238			- Mutators should be protected unless they specifically
239			need to be public. A mutator can ensure that values are
240			checked before being put in to the private attribute.
241
242			- Methods commonly have public access, although private
243			access should be considered if the method is to be used
244			only by the class in which it is placed.
245
246			- Package visibility should also be considered if the use
247			of packages is implemented. Again, each method's use
248			should be considered carefully, and an appropriate
249			access control method chosen.
250
251			- Protected visibility is unlikely to be used as sub-
252			classing any of the classes is unlikely, although if
253			such a situation should arise it should be carefully
254			considered.
255
256			When considering what type of access control to use it is
257			best to be more restrictive than lenient. If a method's
258			visibility is too restrictive then it will be identified
259			more quickly than if the reverse were to happen.
260
261			Imports
262			-------
263
264			The use if the * form of import should be avoided. Each
265			class should be specifically imported as required, and any
266			unused imports should be removed if they are no longer
267			needed. This makes it clear as to exactly what the class is
268			using.
269
270
271			Overall Class Layout
272			--------------------
273
274			The overall layout of a class is important, especially when
275			it comes to reviewing the code at a later stage. Here I will
276			outline the order in which methods and attributes should
277			appear in a class. This psuedo class shows where everything
278			should appear, including imports and package declarations.
279			Commenting will be dealt with in a further section.
280
281			// package declaration
282			package server
283			// imports
284			import java.util.LinkedList
285			import java.io.InputStream
286
287			class MyDummyClass {
288
289			// attributes such as "magic numbers" should be first
290			public static final int S = 1;
291			public static final int E = 3;
292
293			// no-args constructor first
294			public MyDummyClass(){
295			. . .
296			}
297
298			// further constructors follow
299			public MyDummyClass(int x){
300			. . .
301			}
302
303			// public methods
304			public void myMethod(){
305			. . .
306			}
307
308			// private methods
309			private void anotherMethod(){
310			. . .
311			}
312
313			// accessors & mutators
314			public int getMyVar(){
315			. . .
316			}
317
318			// private attributes
319			private int myVar = 5;
320			}
321
322			This layout should be followed in every source file
323			generated. The reason for this structure is that reading
324			downwards you reach the most used methods and attributes
325			first. The exception are the public static final attributes
326			which are put first to allow them to easily be identified
327			and changed at a later date.
328
329			Naming Conventions
330			------------------
331
332			Although this section has been covered throughout the last
333			section, I think it is key that the various naming
334			conventions be clearly identified here. Examples are given
335			for each convention.
336
337			- Packages
338			eg. demo.package
339			Package names should all be in lower case.
340
341			- Files
342			eg. ClassName.java
343			The Java convention is that files have the same name
344			as the class they contain, and the compiler enforces
345			this.
346
347			- Classes
348			eg. ClassName
349			Class names should begin with a capital letter and
350			each new word within the name should begin with a
351			capital letter.
352
353			- Exception Classes
354			eg. ClassNameException
355			Exception classes should follow the same rule as
356			normal classes, but should end with the word
357			Exception.
358
359			- Constants or "magic numbers" (public)
360			eg. MY_STATIC_VARIABLE
361			These public static variables should always be in
362			upper-case. An underscore could be used if required to
363			make the name more readable.
364
365			- Methods
366			eg. methodName()
367			Methods should begin with a lower case letter and each
368			new word within the name should begin with a capital
369			letter.
370
371			- Variables and Attributes
372			eg. variableName
373			Both variables and attributes should being with a
374			lower case letter and each new word within the name
375			should begin with a capital letter - exactly the same
376			as methods.
377
378			- Accessors
379			eg. getVariable()
380			Accessors should follow the same rules as a normal
381			method, but should be named after the variable which
382			they provide access to.
383
384			- Mutators
385			eg. setVariable(...)
386			Mutators should follow the same rules as a normal
387			method, but should be named after the variable to
388			which they control access.
389
390
391			Commenting & Documentation
392			==========================
393
394			All programs should be properly and thoroughly documented.
395			The javadoc tool provides a convention for documenting code
396			and facilitates the automatic generation of program
397			documentation.
398
399			Classes and Interfaces
400			----------------------
401
402			Each class should have a javadoc comment block at the start
403			of the code. This block of comment should be placed in the
404			standard javadoc style / .. / immediately preceding the
405			class header. Package declarations and imports will appear
406			before this initial documentation. Within this section the
407			following items should be included:
408
409			- Class Name
410			- Description of the class and it's use
411			- Revision History
412			- Author(s) - javadoc tag
413			- Version Number - javadoc tag
414
415			It is important to note that as well as the code being read
416			by hand, these comments will also be used to generate
417			information about the class on a webpage using javadoc.
418			Bearing this in mind it may be necessary to use HTML tags to
419			layout the comments, although these should be neatly done so
420			as not to make the comments unreadable in the source code.
421
422			Various javadoc tags should be used to give specific
423			information to the javadoc engine. These should be placed on
424			a separate line.
425
426			- @author <author name>
427			The name of the author, preferably with e-mail address.
428
429			- @version <version number>
430			The version number of the code, with date.
431
432			This is an example of a class header, which contains all of
433			the above items.
434
435			/**
436			* MyClass <br>
437			*
438			* This class is merely for illustrative purposes. <br>
439			*
440			* Revision History:<br>
441			* 1.1 - Added javadoc headers <br>
442			* 1.0 - Original release<br>
443			*
444			* @author T.D.Bishop
445			* @version 1.1, 19/04/2000
446			*/
447			public class MyClass {
448			. . .
449			}
450
451			Methods
452			-------
453
454			Methods should contain a similar javadoc comment to classes,
455			which should be places between / .. / marks immediately
456			preceding the method header. It may not be necessary to do
457			this for all methods, but constructors and major methods
458			certainly should have them, whilst accessors and mutators
459			can have a more cut down version. The following items should
460			be included:
461
462			- Purpose of method
463			- Argument descriptions
464			- Result descriptions
465			- Exceptions thrown
466
467			There are also javadoc tags that can be used specifically
468			for method comments. In a similar way to class comments each
469			begins with an @ and should be placed on a line of it's own.
470
471			- @param <param name> <param description>
472			Should be specified for each parameter that a method
473			takes, with it's name and purpose.
474
475			- @return <description>
476			Describes the result returned by the method.
477
478			- @throws <exception name> <reason for being thrown>
479			Gives the name of any exceptions that may be thrown, and
480			why.
481
482			Here is an example of a method header, showing the above in
483			use.
484
485			/**
486			* This method has no use, and it just illustrative. <br>
487			* Although it does suggest adding the two parameters
488			* together ! <br>
489			*
490			* @param first The first number to be added
491			* @param second The second number to be added
492			* @return The sum of the two parameters
493			* @throws BadException if something goes very wrong !
494			*/
495			public int sumNumbers(int first, int second) throws
496			BadException{
497			. . .
498			}
499
500			Attributes and Variables
501			------------------------
502
503			Attributes and variables require far less commenting than
504			classes and methods. They should simply contain a brief
505			description of what they are used for, and could possibly
506			refer to any accessors or mutators that allow access to
507			them. Attributes that are public static final should have a
508			bit more detailed information as other classes may wish to
509			use them. Here is a basic example:
510
511			/**
512			* This attribute represents the byte value used to start
513			* a packet.
514			*/
515			public static final int ST = 2;
516
517
518			General Commenting
519			------------------
520
521			It is often necessary to add comments within the body of a
522			method. It is preferable to comment in blocks, rather than
523			individually on each line. Likewise it is not necessary to
524			comment code that is obvious in it's purpose. Both single
525			line comments (using //) and multi-line comments (using /*
526			.. */) are acceptable. This is an example of the layout of
527			the two methods:
528
529			int index = 1; // index of starting point
530
531			/* This is a mult-line
532			* comment, and spans
533			* several lines !
534			*/
535
536
537			General Recommendations
538			=======================
539
540			Threading
541			---------
542
543			Threading is a complicated issue, so I will only briefly
544			mention it. The main issue is using the synchronized
545			modifier to prevent deadlock over the system when accessing
546			shared objects. It is important not to overuse this, as it
547			can cause unnecessary deadlock. Use it only when there is a
548			clear need to do so.
549
550			Class Design
551			------------
552
553			Class design should be done in a way that reduces coupling
554			as far as possible. Simply dividing the overall system into
555			clear defined parts is a good way to start this.
556
557			Platform
558			--------
559
560			This document refers to the Java 2 platform (or JDK 1.2).
561			Everything mentioned in this document is based upon this
562			platform and may therefore be out of date in future versions
563			of the Java platform.
564