Contents
Info
Bugs
Docs
Source
Email
Download
Developer
Developer
Projects
Reuse
Policy
Standards
Release Pkg
|
Source Code Standards
The following standards apply to how you write your source code.
The goal has been to minimize.
Requirements
- Package Documentation Is Required
The new JavaDoc provides a new package documentation
mechanism. It is critical that you provide this file
for two reasons. The first is to make sure that there
is sufficient information in the javadoc package overview.
If there are hundreds of package names, and there is
nothing but the package names as a clue to what the
package does, the documentation will be rendered useless.
The second reason is that the GJT release and distribution
system relies on custom tags in this file to operate.
- Class Comments
Classes should not be checked in without a minimum
of a Class comment.
Recommendations
These are recommendations that are intended to
make code on the GJT more consistent and more reusable.
Here is the current list of recommendations:
- Commit Comments
When code is checked in, it should be accompanied by
detailed comments. This helps build a strong history
of bug fixes and improvements, which is invaluable in
maintaining the code.
- Coding Style
There is no standard coding style. However, if you are
adopting a new style for your Java code, you might want
to read
JavaSoft's recommended Java coding style.
- Indenting - tabs vs spaces
Many people feel that using tabs to indent your code is
better than spaces. This allows you to set the indentation
more to your liking, since most editors allow you to set the
number of spaces that a tab indents. Furthermore, editors
deal with tabs better when it comes to "autoindent" features.
|