This document describes a list of coding conventions that are required
for code submissions to the project. By default, the coding conventions
for most Open Source Projects should follow the existing coding conventions
in the code that you are working on. For example, if the bracket is on
the same line as the if statement, then you should write all your code
to have that convention.
このドキュメントでは、プロジェクトに対してコードを提出するのに必要な、
コーディング規約のリストについて説明しています。
たいていのオープンソースプロジェクトのコーディング規約は、
デフォルトでは、あなたが取り組んでいるコードにある、
既存のコーディング規約に従うべきです。
例えば、if 文と同じ行に括弧がある場合には、
あなたは全てその規約にしたがってあなたのコードを書くべきです。
If you commit code that does not follow these conventions and you
are caught, you are responsible for also fixing your own code.
もし、これらの制約にしたがっていないコードをコミットしたら、
責任をもって自分のコードを修正しなければなりません。
Below is a list of coding conventions that are specific to Velocity,
everything else not specificially mentioned here should follow the official
Sun
Java Coding Conventions.
以下は、Velocity 固有のコーディング規約のリストで、その他は特に言及しないかぎり
Sun Java コーディング規約に従います。
1. Brackets should begin and end on a new line. Examples:
1.
括弧の開始・終了は新しい行で行います。
例:
 |
|
|
|
if ( foo )
{
// code here
}
try
{
// code here
}
catch (Exception bar)
{
// code here
}
finally
{
// code here
}
while ( true )
{
// code here
}
|
|
|
|
|
2. It is OK to have spaces between the parens or not. The
preference is to not include the extra spaces. For example, both of these are
ok:
2. 括弧の間にスペースをいれるのは OK です。
ただし、スペースが入れない方が望ましいです。
例えば、これらは両方とも、OK です：
3. 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 enviroment, when the cvs commit messages get sent to a mailing list,
they are almost impossible to read if you use tabs.
3. (インデントは)4つのスペースで。タブはダメです。以上。
多くの人がタブを使いたがるのは理解していますが、実際問題として、
分散開発環境では、タブを使用していると、
cvs コミットメッセージがメーリングリストに送られた時に、
コミットメッセージがほとんど読めません。
In Emacs-speak, this translates to the following command:
(setq-default tab-width 4 indent-tabs-mode nil)
Emacs では、以下のコマンドで変換を行えます。
(setq-default tab-width 4 indent-tabs-mode nil)
4. Unix linefeeds for all .java source code files. Other platform specific
files should have the platform specific linefeeds.
4. .java ソースコードファイルは全て、Unix 改行コードを使用します。
その他のプラットフォーム固有のファイルでは、
プラットフォーム固有の改行を使用します。
5. Javadoc MUST exist on all your methods. 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.
5. すべてのメソッドにjavadocがなければなりません。
また、既存のコードで作業をしていて、javadoc
が無いようなメソッド/クラス/変数などを見つけたら追加してください。
こうしたことで、プロジェクトが全体として改善されます。
6. The Apache Software License MUST be placed at the top
of each and every file.
6. Apache Software License は、
すべてのファイルの先頭に挿入しなければなりません。
7. If you contribute to a file (code or documentation), add yourself to the
top of the file. For java files the preferred Javadoc format is:
7. ファイル(コードやドキュメント)に貢献していただいたら、
自分の名前をファイルの先頭に追加してください。
java ファイルでは、望ましいJavadoc 形式は以下の通りです。
|
|
|
|
@author <a href="mailto:user@domain.com">John Doe</a>
|
|
|
|
|
Thanks for your cooperation.
ご協力をお願いします。
