It's no coincidence that network computers, the Internet and Java have emerged simultaneously as trends in computing - all are "open" technologies that have democratized and universalized the sharing of information. Because it can run on any platform, the 100 per cent Pure Java environment promises to liberate MIS managers from relying on specific, proprietary technologies, including those from the Microsoft and Intel world - software programs no longer need to be written for a specific server or client.
According to a report from Redwood City, CA-based Zona Research, Java: Markets, Opportunities and Trends, 97 per cent of corporations will be using Java for server-based applications within the next two years. In fact, Java has been the fastest growing language/technology in the history of the computer industry.
Network computers free users from using specific desktop devices to access corporate information, PC-style applications and the Internet. Since the storage and processing of data is done at the server level, the expense and complexity of operating systems and microprocessors in network clients becomes more manageable - and less of an issue. Employees don't need to troubleshoot PC problems themselves and MIS managers can more easily manage the network.
The Internet is a kind of glue that connects servers and NCs - it's useful as a communications medium and as a way to distribute Java applets. Like Java and NCs, the Internet is universal - it can be accessed from any platform.
Although NCs can access personal productivity applications from a Windows server, Java software will give many former "greenscreen" users another way to perform functions previously limited to those with PCs - calendaring, word processing, spreadsheets, browsers, groupware and more - without having to take on the overhead of managing a PC. And this new style of server-delivered applications can be used by everyone in the organization, on any system - existing PCs, workstations or NCs.
With Java, IT departments can distribute software programs that can run on any system, from the largest enterprise server to the smallest PC server. And Java allows us to deliver new applications across a diverse range of clients, including PCs, NCs, mobile PCs, mobile NCs, PDAs and digital telephones. Programmers can break up "fat client" software applications into smaller pieces and store them on a central server. The NC user taps only the portions of a program needed to perform a function, while other software functions reside on the server.
When it comes to personal productivity programs, approximately 80 per cent of workers use only 20 per cent of a word processing application. But a Java word processing application divides the functions in a way that makes the most sense - simple typing, highlighting paragraphs or outlining words in bold can be performed at the NC level, while spell-checking can be done at the server level where dictionaries and large databases are stored.
Because all application-specific codes are stored and managed on centralized servers, Java can help reduce development costs, increase a company's return on IT investment and extend the reach of existing products. Other cost savings come in the form of reduced maintenance and fewer software and hardware compatibility problems.
The beauty of NCs is that they allow users to access all kinds of information, such as data residing on the Internet and corporate intranets. Many companies planning to reduce their paper environment and distribute information more quickly and pervasively can now store corporate documents and databases on an intranet. A company's return on investment increases dramatically as its intranet performs more functions and provides more information to users, according to Zona Research - dynamic access to corporate databases leads to an average return on investment of 64 per cent. Users no longer need a complex operating system on their desktops to access a few simple applications and the Internet.
Howie Hunger is director of channels and marketing, IBM Network Computer Division, based in Somers, NY.
Table of Content
1 Introduction
This document lists Java coding recommendations common in the Java development
community.
The recommendations are based on established standards collected from
a number of sources, individual experience, local requirements/needs, as
well as suggestions given in [1],
[2], [3],
[4] and [5].
There are several reasons for introducing a new guideline rather than
just referring to the ones above. Main reason is that these guides are far
too general in their scope and that more specific rules (especially naming
rules) need to be established. Also, the present guide has an annotated
form that makes it far easier to use during project code reviews than most
other existing guidelines. In addition, programming recommendations generally
tend to mix style issues with language technical issues in a somewhat confusing
manner. The present document does not contain any Java technical recommendations
at all, but focuses mainly on programming style.
While a given development environment (IDE) can improve the readability
of code by access visibility, color coding, automatic formatting and so
on, the programmer should never rely on such features. Source code
should always be considered larger than the IDE it is developed
within and should be written in a way that maximize its readability independent
of any IDE.
1.1 Layout of the Recommendations.
The recommendations are grouped by topic and each recommendation is numbered
to make it easier to refer to during reviews.
Layout for the recommendations is as follows:
| Guideline short description |
Example if applicable
|
| Motivation, background and additional information.
|
The motivation section is important. Coding standards and guidelines tend
to start "religious wars", and it is important to state the background for
the recommendation.
1.2 Recommendation Importance
In the guideline sections the terms must, should and
can have special meaning. A must requirement must be followed,
a should is a strong recommendation, and a can is a general
guideline.
2 General Recommendations
| 1. Any violation to the guide is allowed if it enhances
readability. |
| |
| The main goal of the recommendation is to improve
readability and thereby the understanding and the maintainability and
general quality of the code. It is impossible to cover all the specific
cases in a general guide and the programmer should be flexible. |
3 Naming Conventions
3.1 General Naming Conventions
| 2. Names representing packages should be in all lower
case. |
mypackage, com.company.application.ui
|
| Package naming convention used by Sun for the Java
core packages. The initial package name representing the domain name
must be in lower case. |
| 3. Names representing types must be nouns and written
in mixed case starting with upper case. |
Line, AudioSystem
|
| Common practice in the Java development community
and also the type naming convention used by Sun for the Java core packages.
|
| 4. Variable names must be in mixed case starting with
lower case. |
line, audioSystem
|
| Common practice in the Java development community
and also the naming convention for variables used by Sun for the Java
core packages. Makes variables easy to distinguish from types, and effectively
resolves potential naming collision as in the declaration Line line;
|
| 5. Names representing constants (final variables) must
be all uppercase using underscore to separate words. |
MAX_ITERATIONS, COLOR_RED
|
| Common practice in the Java development community
and also the naming convention used by Sun for the Java core packages.
In general, the use of such constants should be minimized. In many
cases implementing the value as a method is a better choice:
int getMaxIterations()
{
return 25;
}
This form is both easier to read, and it ensures a uniform interface
towards class values.
|
| 6. Names representing methods must be verbs and written
in mixed case starting with lower case. |
getName(), computeTotalWidth()
|
| Common practice in the Java development community
and also the naming convention used by Sun for the Java core packages.
This is identical to variable names, but methods in Java are already
distinguishable from variables by their specific form. |
| 7. Abbreviations and acronyms should not be uppercase
when used as name. |
exportHtmlSource();
openDvdPlayer();
|
| Using all uppercase for the base name will give
conflicts with the naming conventions given above. A variable of this
type whould have to be named dVD, hTML etc. which
obviously is not very readable. Another problem is illustrated in the
examples above; When the name is connected to another, the readability
is seriously reduced; The word following the acronym does not stand
out as it should. |
| 8. Private class variables should have underscore (_)
suffix. |
class Person
{
private String name_;
...
}
|
| Apart from its name and its type, the scope
of a variable is its most important feature. Indicating class scope
by using underscore makes it easy to distinguish class variables from
local scratch variables. This is important because class variables are
considered to have higher significance than method variables, and should
be treated with special care by the programmer.
A side effect of the underscore naming convention is that it nicely
resolves the problem of finding reasonable variable names for setter
methods:
void setName (String name)
{
name_ = name;
}
An issue is whether the underscore should be added as a prefix or as
a suffix. Both practices are commonly used, but the latter is recommended
because it seem to best preserve the readability of the name.
It should be noted that scope identification in variables have been
a controversial issue for quite some time. It seems, though, that
this practice now is gaining acceptance and that it is becoming more
and more common as a convention in the professional development community.
|
| 9. Generic variables should have the same name as their
type. |
void setTopic (Topic topic)
void connect (Database database)
|
| Reduce complexity by reducing the number of terms
and names used. Also makes it easy to deduce the type given a variable
name only.
If for some reason this convention doesn't seem to fit
it is a strong indication that the type name is badly chosen.
Non-generic variables have a role. These variables can often
be named by combining role and type:
Point startingPoint, centerPoint;
Name loginName;
|
| 10. All names should be written in English. |
fileName;
|
| English is the preferred language for international
development. |
| 11. Variables with a large scope should have long names,
variables with a small scope can have short names [1].
|
| |
| Scratch variables used for temporary storage or
indices are best kept short. A programmer reading such variables should
be able to assume that its value is not used outside a few lines of
code. Common scratch variables for integers are i, j,
k, m, n and for characters c and
d. |
| 12. The name of the object is implicit, and should
be avoided in a method name. |
line.getLength();
|
| The latter might seem natural in the class declaration,
but proves superfluous in use, as shown in the example. |
3.2 Specific Naming Conventions
| 13. The terms get/set must be used where an
attribute is accessed directly. |
employee.getName();
matrix.getElement (2, 4);
employee.setName (name);
matrix.setElement (2, 4, value);
|
| This is the naming convention for accessor methods
used by Sun for the Java core packages. When writing Java beans this
convention is actually enforced. |
| 14. is prefix should be used for boolean variables
and methods. |
isSet, isVisible, isFinished, isFound, isOpen
|
| This is the naming convention for boolean methods
and variables used by Sun for the Java core packages. When writing Java
beans this convention is actually enforced for methods.
Using the is prefix solves a common problem of choosing
bad boolean names like status or flag. isStatus
or isFlag simply doesn't fit, and the programmer is forced
to chose more meaningful names.
There are a few alternatives to the is prefix that fits
better in some situations. These are has, can and
should prefixes:
boolean hasLicense();
boolean canEvaluate();
boolean shouldAbort = false;
|
| 15. The term compute can be used in methods
where something is computed. |
valueSet.computeAverage();
matrix.computeInverse();
|
| Give the reader the immediate clue that this is
a potential time consuming operation, and if used repeatedly, he might
consider caching the result. Consistent use of the term enhances readability.
|
| 16. The term find can be used in methods where
something is looked up. |
vertex.findNearestVertex();
matrix.findMinElement();
|
| Give the reader the immediate clue that this is
a simple look up method with a minimum of computations involved. Consistent
use of the term enhances readability. |
| 17. The term initialize can be used where
an object or a concept is established. |
printer.initializeFontSet();
|
| The American initializeshould be preferred
over the English initialise. Abbreviation init must
be avoided. |
| 18. JFC (Java Swing) variables should be suffixed by
the element type. |
widthScale, nameTextField, leftScrollbar, mainPanel, fileToggle, minLabel,
printerDialog
|
| Enhances readability since the name gives the user
an immediate clue of the type of the variable and thereby the available
resources of the object. |
| 19. Plural form should be used on names representing
a collection of objects. |
Collection points;
int[] values;
|
| Enhances readability since the name gives the user
an immediate clue of the type of the variable and the operations that
can be performed on the object. |
| 20. n prefix should be used for variables
representing a number of objects. |
nPoints, nLines
|
| The notation is taken from mathematics where it
is an established convention for indicating a number of objects.
Note that Sun use num prefix in the core Java packages
for such variables. This is probably meant as an abbreviation of number
of, but as it looks more like number it makes the variable
name strange and misleading. If "number of" is the preferred statement,
numberOf prefix can be used instead of just n. num
prefix must not be used.
|
| 21.No suffix should be used for variables
representing an entity number. |
tableNo, employeeNo
|
| The notation is taken from mathematics where it
is an established convention for indicating an entity number.
An elegant alternative is to prefix such variables with an i:
iTable, iEmployee. This effectively makes them named
iterators.
|
| 22. Iterator variables should be called i,
j, k etc. |
while (Iterator i = points.iterator(); i.hasNext(); ) {
:
}
for (int i = 0; i < nTables; i++) {
:
}
|
| The notation is taken from mathematics where it
is an established convention for indicating iterators.
Variables named j, k etc. should be used for nested
loops only.
|
| 23. Complement names must be used for complement entities
[1]. |
get/set, add/remove, create/destroy, start/stop, insert/delete,
increment/decrement, old/new, begin/end, first/last, up/down, min/max,
next/previous, old/new, open/close, show/hide
|
| Reduce complexity by symmetry. |
| 24. Abbreviations in names should be avoided. |
computeAverage();
ActionEvent event;
|
| There are two types of words to consider. First
are the common words listed in a language dictionary. These must never
be abbreviated. Never write:
cmd instead of command
comp instead of compute
cp instead of copy
e instead of exception
init instead of initialize
pt instead of point
etc.
Then there are domain specific phrases that are more naturally known
through their acronym or abbreviations. These phrases should be kept
abbreviated. Never write:
HypertextMarkupLanguage instead of html
CentralProcessingUnit instead of
cpu
PriceEarningRatio instead of
pe
etc.
|
| 25. Negated boolean variable names must be avoided.
|
boolean isError;
boolean isFound;
|
| The problem arise when the logical not operator
is used and double negative arises. It is not immediately apparent what
!isNotError means. |
| 26. Associated constants (final variables) should be
prefixed by a common type name. |
final int COLOR_RED = 1;
final int COLOR_GREEN = 2;
final int COLOR_BLUE = 3;
|
| This indicates that the constants belong together,
and what concept the constants represents.
An alternative to this approach is to put the constants inside an
interface effectively prefixing their names with the name of the interface:
interface Color
{
final int RED = 1;
final int GREEN = 2;
final int BLUE = 3;
}
|
| 27. Exception classes should be suffixed with Exception.
|
class AccessException
{
:
}
|
| Exception classes are really not part of the main
design of the program, and naming them like this makes them stand out
relative to the other classes. This standard is followed by Sun in the
basic Java library. |
| 28. Default interface implementations can be prefixed
by Default. |
class DefaultTableCellRenderer
implements TableCellRenderer
{
:
}
|
| It is not uncommon to create a simplistic class
implementation of an interface providing default behaviour to the interface
methods. The convention of prefixing these classes by Default
has been adopted by Sun for the Java library. |
| 29. Functions (methods returning an object) should
be named after what they return and procedures (void methods)
after what they do. |
| |
| Increase readability. Makes it clear what the unit
should do and especially all the things it is not supposed
to do. This again makes it easier to keep the code clean of side effects.
|
4 Files
| 30. Java source files should have the extension .java.
|
Point.java
|
| Enforced by the Java tools. |
| 31. Classes should be declared in individual files
with the file name matching the class name. Secondary private classes
can be declared as inner classes and reside in the file of the class
they belong to. |
| |
| Enforced by the Java tools. |
| 32. File content must be kept within 80 columns. |
| |
| 80 columns is the common dimension for editors,
terminal emulators, printers and debuggers, and files that are shared
between several developers should keep within these constraints. It
improves readability when unintentional line breaks are avoided when
passing a file between programmers. |
| 33. Special characters like TAB and page break must
be avoided. |
| |
| These characters are bound to cause problem for
editors, printers, terminal emulators or debuggers when used in a multi-programmer,
multi-platform environment. |
| 34. The incompleteness of split lines must be made
obvious [1]. |
totalSum = a + b + c +
d + e;
function (param1, param2,
param3);
setText ("Long line split" +
"into two parts.");
for (tableNo = 0; tableNo < maxTable;
tableNo += tableStep)
|
| Split lines occurs when a statement exceed the
80 column limit given above. It is difficult to give rigid rules for
how lines should be split, but the examples above should give a general
hint.
In general:
- Break after a comma.
- Break after an operator.
- Align the new line with the beginning of the
expression on the previous line.
|
5 Statements
5.1 Package and Import Statements
| 35. The package statement must be the first
statement of the file. All files should belong to a specific package.
|
| |
| The package statement location is enforced
by the Java language. Letting all files belong to an actual (rather
than the Java default) package enforces Java language object oriented
programming techniques. |
| 36. The import statements must follow the
package statement. import statements should be sorted
with the most fundamental packages first, and grouped with associated
packages together and one blank line between groups. |
import java.io.*;
import java.net.*;
import java.rmi.*
import java.rmi.server.*;
import javax.swing.*;
import javax.swing.event.*;
import org.linux.apache.server.*;
|
| The import statement location is enforced
by the Java language. The sorting makes it simple to browse the list
when there are many imports, and it makes it easy to determine the dependiencies
of the present package The grouping reduce complexity by collapsing
related information into a common unit. |
5.2 Classes and Interfaces
37. Class and Interface declarations should be organized
in the following manner:
- Class/Interface documentation.
- class or interface statement.
- Class (static) variables in the order public,
protected, package (no access modifier), private.
- Instance variables in the order public, protected,
package (no access modifier), private.
- Constructors.
- Methods (no specific order).
|
| |
| Reduce complexity by making the location of each
class element predictable. |
5.3 Methods
38. Method modifiers should be given in the following
order:
<access> static abstract synchronized <unusual> final
native
The <access> modifier (if present) must be the first
modifier. |
| |
| <access> is one of public,
protected or private while <unusual>
includes volatile and transient. The most important
lesson here is to keep the access modifier as the first modifier.
Of the possible modifiers, this is by far the most important, and it
must stand out in the method declaration. For the other modifiers, the
order is less important, but it make sense to have a fixed convention.
|
5.4 Types
| 39. Type conversions must always be done explicitly.
Never rely on implicit type conversion. |
floatValue = (float) intValue;
|
| By this, the programmer indicates that he is aware
of the different types involved and that the mix is intentional. |
5.5 Variables
| 40. Variables should be initialized where they are
declared and they should be declared in the smallest scope possible.
|
| |
| This ensures that variables are valid at any time.
Sometimes it is impossible to initialize a variable to a valid value
where it is declared. In these cases it should be left uninitialized
rather than initialized to some phony value. |
| 41. Variables must never have dual meaning. |
| |
| Enhances readability by ensuring all concepts are
represented uniquely. Reduce chance of error by side effects. |
| 42. Class variables should never be declared public.
|
| |
| The concept of Java information hiding and encapsulation
is violated by public variables. Use private variables and access functions
instead. One exception to this rule is when the class is essentially
a data structure, with no behavior (equivalent to a C++ struct).
In this case it is appropriate to make the class' instance variables
public [2]. |
43. Related variables of the same type can be declared
in a common statement.
Unrelated variables should not be declared in the same statement. |
float x, y, z;
float revenueJanuary, revenueFebrury, revenueMarch;
|
| The common requirement of having declarations on
separate lines is not useful in the situations like the ones above.
It enhances readability to group variables. Note however that whenever
possible, values should be initialized where they are declared (see
Rule #40), in case this situation doesn't arise. |
| 44. Arrays should be declared with their brackets next
to the type. |
double[] vertex;
int[] count;
public static void main (String[] arguments)
public double[] computeVertex()
|
| The reason for is twofold. First, the array-ness
is a feature of the class, not the variable. Second, when returning
an array from a method, it is not possilble to have the brackets with
other than the type (as shown in the last example). |
| 45. Variables should be kept alive for as short a time
as possible. |
| |
| Keeping the operations on a variable within a small
scope, it is easier to control the effects and side effects of the variable.
|
5.6 Loops
| 46. Only loop control statements must be included in
the for() construction. |
sum = 0;
for (i = 0; i < 100; i++)
sum += value[i];
|
| Increase maintainability and readability. Make
a clear distinction of what controls and what is contained
in the loop. |
| 47. Loop variables should be initialized immediately
before the loop. |
boolean isDone = false;
while (!isDone) {
:
}
|
| |
| 48. The use of do .... while loops should
be avoided. |
| |
There are two reasons for this. First is that the
construct is superflous; Any statement that can be written as a do
.... while loop can equally well be written as a while
loop or a for loop. Complexity is reduced by minimizing the
number of constructs being used.
The other reason is of readability. A loop with the conditional part
at the end is more difficult to read than one with the conditional at
thetop. |
| 49. The use of break and continue
in loops should be avoided. |
| |
| These statements should only be used if they prove
to give higher readability than their structured counterparts. |
5.7 Conditionals
| 50. Complex conditional expressions must be avoided.
Introduce temporary boolean variables instead [1].
|
if ((elementNo < 0) || (elementNo > maxElement)||
elementNo == lastElement) {
:
}
should be replaced by:
boolean isFinished = elementNo < 0 || elementNo > maxElement;
boolean isRepeatedEntry = elementNo == lastElement;
if (isFinished || isRepeatedEntry) {
:
}
|
| By assigning boolean variables to expressions,
the program gets automatic documentation. The construction will be easier
to read, debug and maintain. |
| 51. The nominal case should be put in the if-part
and the exception in the else-part of an if statement [1].
|
boolean isError = readFile (fileName);
if (!isError) {
:
}
else {
:
}
|
| Makes sure that the exceptions does not obscure
the normal path of execution. This is important for both the readability
and performance. |
| 52. The conditional should be put on a separate line.
|
if (isDone)
doCleanup();
|
| This is for debugging purposes. When writing on
a single line, it is not apparent whether the test is really true or
not. |
| 53. Executable statements in conditionals must be avoided.
|
file = openFile (fileName);
if (file != null) {
:
}
|
| Conditionals with executable statements are simply
very difficult to read. This is especially true for programmers new
to Java. |
5.8 Miscellaneous
| 54. The use of magic numbers in the code should be
avoided. Numbers other than 0 and 1can be considered
declared as named constants instead. |
private static final int TEAM_SIZE = 11;
:
Player[] players = new Player[TEAM_SIZE];
|
| If the number does not have an obvious meaning
by itself, the readability is enhanced by introducing a named constant
instead. |
| 55. Floating point constants should always be written
with decimal point and at least one decimal. |
double total = 0.0;
double speed = 3.0e8;
double sum;
:
sum = (a + b) * 10.0;
|
| This emphasize the different nature of integer
and floating point numbers. Mathematically the two model completely
different and non-compatible concepts.
Also, as in the last example above, it emphasize the type of the
assigned variable (sum) at a point in the code where this
might not be evident.
|
| 56. Floating point constants should always be written
with a digit before the decimal point. |
double total = 0.5;
|
| The number and expression system in Java is borrowed
from mathematics and one should adhere to mathematical conventions for
syntax wherever possible. Also, 0.5 is a lot more readable than .5;
There is no way it can be mixed with the integer 5. |
| 57. Static variables or methods must always be refered
to through the class name and never through an instance variable. |
Thread.sleep (1000);
|
| This emphasize that the element references is static
and independent of any particular instance. For the same reason the
class name should also be included when a variable or method is accessed
from within the same class. |
6 Layout and Comments
6.1 Layout
| 58. Basic indentation should be 2. |
for (i = 0; i < nElements; i++)
a[i] = 0;
|
| Indentation is used to emphasize the logical structure
of the code. Indentation of 1 is to small to acheive this. Indentation
larger than 4 makes deeply nested code difficult to read and increase
the chance that the lines must be split. Choosing between indentation
of 2, 3 and 4; 2 and 4 are the more common, and 2 chosen to reduce the
chance of splitting code lines. Note that the Sun recommendation on
this point is 4. |
| 59. Block layout should be as illustrated
in example 1 below (recommended) or example 2, and must not be as shown
in example 3. Class, Interface and method blocks should use the block
layout of example 2. |
while (!isDone) {
doSomething();
isDone = moreToDo();
}
|
while (!isDone)
{
doSomething();
isDone = moreToDo();
}
|
while (!isDone)
{
doSomething();
isDone = moreToDo();
}
|
| Example 3 introduce an extra indentation
level which doesn't emphasize the logical structure of the code as clearly
as example 1 and 2. |
| 60. The class or interface declarations
should have the following form: |
class SomeClass extends AnotherClass
implements SomeInterface, AnotherInterface
{
...
}
|
| This follows from the general block rule above.
Note that it is common in the Java developer community to have the opening
bracket at the end of the line of the class keyword. This is not recommended.
|
| 61. The method declarations should have the following
form: |
public void someMethod ()
throws SomeException
{
...
}
|
| See comment on class statements above.
|
| 62. The if-else class of statements should
have the following form: |
if (condition) {
statements;
}
if (condition) {
statements;
}
else {
statements;
}
if (condition) {
statements;
}
else if (condition) {
statements;
}
else {
statements;
}
|
This follows partly from the general block rule
above. However, it might be discussed if an else clause should
be on the same line as the closing bracket of the previous if
or else clause:
if (condition) {
statements;
} else {
statements;
}
This is equivalent to the Sun recommendation. The chosen approach is
considered better in the way that each part of the if-else
statement is written on separate lines of the file. This should make
it easier to manipulate the statement, for instance when moving else
clauses around. |
| 63. The for statement should have the following
form: |
for (initialization; condition; update) {
statements;
}
|
| This follows from the general block rule above.
|
| 64. An empty for statement should have the
following form: |
for (initialization; condition; update)
;
|
| This emphasize the fact that the for statement
is empty and it makes it obvious for the reader that this is intentional.
|
| 65. The while statement should have the following
form: |
while (condition) {
statements;
}
|
| This follows from the general block rule above.
|
| 66. The do-while statement should have the
following form: |
do {
statements;
} while (condition);
|
| This follows from the general block rule above.
|
| 67. The switch statement should have the following
form: |
switch (condition) {
case ABC :
statements;
case DEF :
statements;
break;
case XYZ :
statements;
break;
default :
statements;
break;
}
|
| This differs slightly from the Sun recommendation
both in indentation and spacing. In particular, each case keyword
is indented relative to the switch statement as a whole. This makes
the entire switch statement stand out. Note also the extra space before
the : character. The explicit Fallthrough comment
should be included whenever there is a case statement without a break
statement. Leaving the break out is a common error, and it
must be made clear that it is intentional when it is not there. |
| 68. A try-catch statement should have the
following form: |
try {
statements;
}
catch (Exception exception) {
statements;
}
try {
statements;
}
catch (Exception exception) {
statements;
}
finally {
statements;
}
|
| This follows partly from the general block rule
above. This form differs from the Sun recommendation in the same way
as the if-else statement described above. |
| 69. Single statement if-else, for
or while statements can be written without brackets. |
if (condition)
statement;
while (condition)
statement;
for (initialization; condition; update)
statement;
|
| It is a common recommendation (Sun Java recommendation
included) that brackets should always be used in all these cases. However,
brackets are in general a language construct that groups several statements.
Brackets are per definition superfluous on a single statement. A common
argument against this syntax is that the code will break if
an additional statement is added without also adding the brackets. In
general however, code should never be written to accommodate for changes
that might arise. |
6.2 White Space
70.
- Operators should be surrounded by a space character.
- Java reserved words should be followed by a white space.
- Commas should be followed by a white space.
- Colons should be surrounded by white space.
- Semicolons in for statements should be followed by a space character.
|
a = (b + c) * d;
while (true) {
doSomething (a, b, c, d);
case 100 :
for (i = 0; i < 10; i++) {
|
| Makes the individual components of the statements
stand out and enhances readability. It is difficult to give a complete
list of the suggested use of whitespace in Java code. The examples above
however should give a general idea of the intentions. |
| 71. Function names should be followed by a white space
when it is followed by another name. |
doSomething (parameter);
doSomething();
|
| Makes the individual names stand out and enhances
readability. When no name follows, the space can be omitted since there
is no doubt about the name in this case. An alternative to this approach
is to require a space after the opening parenthesis. Those
that adhere to this standard usually also leave a space before the closing
parentheses: doSomething( parameter );. This do make the individual
names stand out as is the intention, but the space before the closing
parenthesis is rather artificial, and without this space the statement
looks rather asymmetrical (doSomething( parameter);). |
| 72. Logical units within a block should be separated
by one blank line. |
Matrix4x4 matrix = new Matrix4x4();
double cosAngle = Math.cos (angle);
double sinAngle = Math.sin (angle);
matrix.setElement (1, 1, cosAngle);
matrix.setElement (1, 2, sinAngle);
matrix.setElement (2, 1, -sinAngle);
matrix.setElement (2, 2, cosAngle);
multiply (matrix);
|
| Enhances readability by introducing white space
between logical units of a block. |
| 73. Methods should be separated by 3-5 blank lines.
|
| |
| By making the space larger than space within a
method, the methods will stand out within the class. |
| 74. Variables in declarations should be left aligned.
|
TextFile file;
int nPoints;
double x, y;
|
| Enhances readability. The variables are easier
to spot from the types by alignment. |
| 75. Statements should be aligned wherever this enhances
readability. |
if (a == lowValue) compueSomething();
else if (a == mediumValue) computeSomethingElse();
else if (a == highValue) computeSomethingElseYet();
value = (potential * oilDensity) / constant1 +
(depth * waterDensity) / constant2 +
(zCoordinateValue * gasDensity) / constant3;
minPosition = computeDistance (min, x, y, z);
averagePosition = computeDistance (average, x, y, z);
switch (value) {
case PHASE_OIL : phaseString = "Oil"; break;
case PHASE_WATER : phaseString = "Water"; break;
case PHASE_GAS ; : phaseString = "Gas"; break;
}
|
| There are a number of places in the code where
white space can be included to enhance readability even if this violates
common guidelines. Many of these cases have to do with code alignment.
General guidelines on code alignment are difficult to give, but the
examples above should give some general hints. In short, any construction
that enhances readability should be allowed. |
6.3 Comments
| 76. Tricky code should not be commented but rewritten
[1]. |
| |
| In general, the use of comments should be minimized
by making the code self-documenting by appropriate name choices and
an explicit logical structure. |
| 77. All comments should be written in English. |
| |
| In an international environment English is the
preferred language. |
| 78. Use // for all non-JavaDoc comments, including
multi-line comments. |
|
| Since multilevel Java commenting is not supported,
using // comments ensure that it is always possible to comment out entire
sections of a file using /* */ for debugging purposes etc. |
| 79. Comments should be indented relative to their position
in the code [1]. |
while (true) {
something();
}
|
| This is to avoid that the comments break the logical
structure of the program. |
| 80. The declaration of collection variables
should be followed by a comment stating the common type of the elements
of the collection. |
private Vector points_;
private Set shapes_;
|
| Without the extra comment it can be hard to figure
out what the collection consist of, and thereby how to treat the elements
of the collection. In methods taking collection variables as input,
the common type of the elements should be given in the associated JavaDoc
comment. |
| 81. All public classes and public and protected functions
within public classes should be documented using the Java documentation
(javadoc) conventions. |
| |
| This makes it easy to keep up-to-date online code
documentation. |
7 References
[1] Code Complete, Steve McConnel - Microsoft Press
[2] Java Code Conventions
http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
[3] Netscape's Software Coding Standards for Java
http://developer.netscape.com/docs/technote/java/codestyle.html
[4] C / C++ / Java Coding Standards from NASA
http://v2ma09.gsfc.nasa.gov/coding_standards.html
[5] Coding Standards for Java from AmbySoft
http://www.ambysoft.com/javaCodingStandards.html
|