Release Pkg

Source Code Standards

The following standards apply to how you write your source code. The goal has been to minimize.


  • 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.


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.

All contents are copyrighted (c) by their respective authors. All rights reserved.
All contents are licensed under the General Public License.