The primary source for JOSSE coding standards is "The Elements of Java
Style" (EJS) by Allen Vermeulen et al. You should have read this book
cover to cover more than one time by the end of this course. It is the most
concise and lucid summary of Java coding best practices I have seen to
date. For the most concise and lucid summary of Java programming best
practices, see "Effective Java" by Joshua Bloch.
Beyond the material in these books, this course includes a small number of
additional coding and programming standards:
 | [J.01] All programs should be developed in a subpackage of the package
edu.hawaii.
You are free to decide what subpackage name to use. A reasonable
decision is the name of the project: for example, edu.hawaii.accountinfo1.
Another possibility is to use both your username and the project name; for
example, edu.hawaii.johnson.accountinfo1. (Don't use my username, of
course.)
|
| [J.02] Do not use the wildcard "*" in import statements.
You must explicitly import each class that you use from other packages.
This is an important form of documentation to readers of your class.
It is also enforced by CheckStyle.
|
| [J.03] Only one java statement per line.
EJS does not explicitly prohibit multiple statements on a single line, but
we do.
|
| [J.04] All summary lines (i.e. The first words to appear in a package,
class, and method javadoc comment) must be a complete sentence both
grammatically and syntactically.
For example, the summary line must start with a capitalized letter, and
end with a period. This is enforced beginning with javadoc in jdk1.4.
|
| [J.05] Use Eclipse 2.1, Tomcat 4.1.27, and Java 1.4.2.
This avoids configuration problems.
|
| [J.06] All <table>, <form>, and <a> HTML elements
should include an "id" attribute with a value that uniquely
identifies that element within that page.
This enables you to write HttpUnit tests that access that table, form, and
link more easily and which will not break if you move the table, form, or
link around on the page.
|
| [J.07] Minimize scriptlets.
Sometimes they are unavoidable, but usually they are if you use the right
tag library.
|
| [J.08] Always check parameters for existence and validity.
Do not assume that because your page always passes a parameter with the
correct value, that you do not need to check the parameter validity inside
your server-side code. Be defensive and assume that other pages might
be written that do not do the right thing, or that a user will construct an
URL that has unexpected parameter data.
|
| [J.09] Do not include // comments at the top of a file.
Most of that information should be included in the JavaDoc class
documentation. |
