For class and method declaration, brackets should begin and end on a new line. Example :

クラスやメソッドの宣言では、 括弧は新しい行で始まり、終らなければなりません。 例えば次のようになります :

public class SomeClass
{
    public void someMethod()
    {
    }
}

Brackets for blocks of code inside methods should begin and end on the same line (this applies to if, for, while, try/catch, ...). Example :

メソッド中のコードブロックの括弧は、 同じ行で始まり、終らなければなりません。 (これは、if、for、while、 try/catch、などに対して適用されます) 例えば次のようになります :

public void someMethod()
{
    if (expression) {
    } else if (other_expression) {
    }

    try {
    } catch (Exception e) {
    }
}

Brackets are mandatory even for single line statements !

括弧をつけることは、一行の文に対しても義務付けられています。

// Incorrect
// 誤り
if (式/expression)
    // 何かのコード/some code

// Correct
// 正しい
if (式/expression) {
    // 何かのコード/some code
}

keywords followed by a parenthesis should be separated by a space. Example :

括弧のついたキーワードはスペースで区切られなければなりません。 例 :

while (true) {
    // 何かのコード/some code
}

Blank space should appear after commas in argument lists. Binary operators should be separated from their operands by spaces :

引数リスト中のカンマの後には空白がなければなりません。 二項演算子はその演算記号をスペースで区切らなければなりません :

a += c + d;
a = (a + b) / (c * d);

while (d++ = s++) {
    n++;
}

printSize("size is " + foo + "\n");

4 spaces. NO tabs. Period. We understand that a lot of you like to use tabs, but the fact of the matter is that in a distributed development environment, when the cvs commit messages get sent to a mailing list, they are almost impossible to read if you use tabs.

4 つの空白記号で、タブは無し。以上です。 皆さんの多くがタブを使いがちなのは知っていますが、 実際問題、分散開発環境においては、 cvs コミットメッセージがメーリングリストに送られるとき、 タブを使った場合、ほとんど読めないという事があるのです。

Javadoc SHOULD exist on all your class members (methods + class variables), including the private ones. Also, if you are working on existing code and there currently isn't a javadoc for that method/class/variable or whatever, then you should contribute and add it. This will improve the project as a whole.

自分の全てのクラスのメンバー(メソッド + クラス変数)には、 プライベートなものも含めて、 javadoc がなければなりません。 また、既存のコードで作業していて、 現状ではそのメソッド/クラス/変数に javadoc が無いなどの問題があったとき、 貢献して加えてください。 この事がプロジェクト全体を推進させるのです。

Also add code comments when you think it's necessary (like assumptions), especially when the code is not obvious.

また、(仮定のように)必要だと感じた場合、 特にコードが明瞭でない場合には、 コードにコメントを加えてください。

The Jakarta Apache/Cactus License MUST be placed at the top of each and every file.

Jakarta Apache/Cactus ライセンスは 個々の全てのファイルの先頭に置かなければなりません。

If you contribute to a file (code or documentation), add yourself to the top of the file (below the existing authors). For java files the preferred Javadoc format is:

ファイル(コードやドキュメント)に対して貢献した場合、 ファイルの先頭に(既存の作者の下に)自分の名前を加えることができます。 java ファイルの場合、 推奨される javadoc フォーマットは次の通りです:

@author <a href="mailto:user@domain.com">John Doe</a>

Class variables should not have any prefix and must be referenced using the this object. Example :

Class variables should not have any prefix クラス変数は何も前にあってはならず、 this オブジェクトを使って 参照されなければなりません。例えば次のようになります :

public class SomeClass
{
    private String someString;
[...]
    public void someMethod()
    {
        logger.debug("Value = " + this.someString);
    }
}

Method parameters should be prefixed by "the" (for differentiating them from inner variables). For example :

メソッド引数名は必ず "the" で始らなければなりません。 (内部変数と区別するためにです。) 例えば次のようになります :

public void someMethod(String theClassName)
{
    String className; // 内部変数/inner variable
}

Avoid lines longer than 80 characters for Code, comments, ...

コードやコメントで一行が 80 文字以上になるのを避けてください。

All .java files should have a @version tag like the one below.

全ての .java ファイルには下に示すような @version タグが無ければなりません :

@version $Id: coding_conventions.xml,v 1.1 2002/03/10 14:10:25 vmassol Exp $

Do not use System.out to log. Instead, use the Cactus logging classes which are a facade to Log4j. Use the name of your class as the Log4j Category. For example :

決してログ出力するのに System.out を 使わないでください。 代りに、Log4j を使った Cactus のロギングクラスを使ってください。 Log4j Category として自分のクラス名を使ってください。 例は次の通りです :

private static Log logger =
		LogService.getInstance().getLog(MyClass.class.getName());

public void someMethod()
{
		logger.debug("some debug text");
}

As of Cactus 1.3, LogAspect autmatically logs all method entries and exits.

Cactus 1.3 では LogAspect は自動的に全てのメソッドの開始と終了がログ出力されます。

Managing exceptions correctly requires experience. This is not supposed to be a guide on managing exceptions, simply a few best practices.

例外処理を正しく扱うには経験が必要です。 これは、例外処理を扱うガイドとして書かれたのではなく、 単に幾つかの最良の実例を示しただけです。

• Rule 1 : Try to catch exceptions as much as possible and rethrow higher level exceptions (meaning hiding the low level detailed and putting a message that is more related to the function of your code).
• ルール 1 : できる限り多くの例外をキャッチして、上のレベルの例外にスローしようとしてみてください。(これは、低いレベルの詳細を隠蔽し 自分のコードの関数により関係するメッセージを出力することを意味します)
• Rule 2 : It is important not to loose the stack trace which contains important information. Use chained exceptions for that. Cactus provides a ChainedRuntimeException for chaining runtime exceptions.
• ルール 2 : 重要な情報が含まれているスタックトレースを無くさないことが大切です。 連鎖となったランタイムの例外のために、 Cactus では ChainedRuntimeException を提供しています。
• Rule 3 : Always log the exception at the higher level (ie. where it is handled and not rethrown).
• ルール 3 : 常に上のレベルで例外のログを取ってください。 (即ち、そこで処理され再スローされない所で)
• Rule 4 : Try to avoid catching Throwable or Exception and catch specific exceptions instead.
• ルール 4 : Throwable あるいは Exception を キャッチせず、代りに特定の例外をキャッチするように心がけてください。

An example :

例 :

public void getTestClass()
{
    try {
        Class responseClass =
            Class.forName("some.package.MyClass");
    } catch (ClassNotFoundException cnfe) {
        String message = "Cannot instantiate test class";
        logger.error(message);
        throw new ChainedRuntimeException(message, e);
    }
}

All import statements should containing the full class name of classes to import and should not use the "*" notation :

全ての import 宣言には、 インポートするクラスのクラス名全体を入れるようにし、 "*" による表記を使わないようにしてください :

An example :

例 :

// 正しい/Correct
import java.util.Date;
import java.net.HttpURLConnection;

// 誤り/Not correct
import java.util.*;
import java.net.*;