目次
コーディング規約の必要性
コーディング規約とはJava言語で開発するときのルールのことです。開発現場では現場毎にコーディング規約があるのが一般的です。そしてソースレビューはこのコーディング規約に沿って作られているかの確認を行います。
スポンサーリンク
しかし、コーディング規約がない現場も存在します。一人ですべて開発しているのであれば、それで良いのかもしれませんが、複数人で開発している場合は人によってソースの書き方が変わってしまいます。見るソースによって書き方が違う統一性のないソースコードになってしまいます。
コーディング規約がないとメンテナンス性の低いソースコードになってしまう危険性があるのです。
【コーディングの心得5か条】
- 見やすさを重視せよ
- ネーミングはわかりやすく
- サンプルを鵜呑みにしない
- 同じコードを二度書かない
- 役割は一つに
最低限守りたいコーディング規約その1「命名規約」
意外と大切なのが命名規約です。変数名を「a」とか「string1」など意味のないつけ方をする人や意味のある変数名をつけているが、適切ではない名前にしている人もいます。
「システムが動けばいいんだから気にしすぎ」と思う人もいるかもしれませんが、意味のわからない変数名は、ソースを見にくく理解し難いものにしてしまいます。ソース規模が大きければ大きいほど「命名規約」は守っておきたいものです。
パッケージ名の命名規約
パッケージ名の命名規約は以下です。
- すべて小文字
- 意味のある名前にする
- サブパッケージ名の重複は可能
クラス名の命名規約
クラス名の命名規約は以下です。
- 単語の先頭を大文字にする
- 意味のある名前にする
良い例 (車管理クラス)
public class CarManage {悪い例 (車管理クラス)
public class carmanage {メソッド名の命名規約
メソッド名の命名規約は以下です。
- メソッド名は区切りのみ大文字にする（先頭は小文字）
- 意味のある名前にする
スポンサーリンク
良い例 (タイヤ取得メソッド)
public class getTire {悪い例 (タイヤ取得メソッド)
public class GetTire {変数の命名規約
変数の命名規約は以下です。
- boolean変数はtrue/false の状態がわかるようにする
- 変数名は区切りのみ大文字にする（先頭は小文字）
- 意味のある名前にする
boolean変数の良い例 (成功かどうかのフラグ)
private boolean isSuccess;
boolean変数の悪い例 (成功かどうかのフラグ)
private boolean flag;
定数の命名規約
定数の命名規約は以下です。
- すべて大文字、区切りは"_"
- 意味のある名前にする
良い例
private static final String SYSTEM_NAME = "車システム";
悪い例
private static final String SystemName = "車システム";
最低限守りたいコーディング規約その2「メモリの解放」
Javaでメモリを解放する処理はClose関数を使用します。Close関数を使用しなくても大きな問題にはなりませんが、負荷が大きいシステムなどではメモリリークになる危険性もあるので、しっかり解放処理を行うのが基本です。
以下はファイルを読み込むサンプルプログラムです。
public class SampleTryWithResources {
public static void main(String[] args) {
BufferedReader br = new BufferedReader(new FileReader("sample.txt"));
String line = null;
while ((line = br.readLine()) != null) {
System.out.println(line);
}
br.close();
}
}良くあるのが上記のパターン。一見問題ないようにも見えますが、例外が発生した場合、close処理を通りません。
以下のようにfinallyで確実にcloseする方が無難です。良いソースを書くプログラマーはこの辺りの異常系への配慮がしっかりされています。
そのため、異常発生時でも特に問題になることなく動作することが多いです。
またJavaSE7から「try-with-resources」文追加されています。C#でいうusingと同じ役割なので、確実にclose処理が通るようになっています。なるべく「try-with-resources」を使うことをお勧めします。
public class SampleTryWithResources {
public static void main(String[] args) {
BufferedReader br = null;
try {
br = new BufferedReader(new FileReader("sample.txt"));
String line = null;
while ((line = br.readLine()) != null) {
System.out.println(line);
}
} finally {
if (br != null)
{
try {
br.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
}
}以下が「try-with-resources」文のサンプルです。
try (BufferedReader br = new BufferedReader(new FileReader("sample.txt"))) {
String line = null;
while ((line = br.readLine()) != null) {
System.out.println(line);
}
} catch (Exception e) {
e.printStackTrace();
}
}最低限守りたいコーディング規約その3「メソッド内のコード量」
Javaはオブジェクト指向の言語です。ソースは部品化して使用することが大切です。
スポンサーリンク
1つのメソッドに処理を長々と書くのは良くありません。理由は「見にくい」そして「メンテナンス性が悪い」からです。
メソッド内の一部分を修正したとき、メソッドを部品化しているのであれば、部品化した短い内容のメソッドのテストを重点的に行えばよいですが（※もちろん呼び出し元の確認も必要）、1つのメソッドに長々と書いている場合、想定されるテストケースは部品化したメソッドと比べると明らかに多くなります。
最低限守りたいコーディング規約その4「同じ処理を書かない、共通化する」
色々な箇所に同じ処理を書いているプロジェクトを見たことありませんか？意外と多いです。
例えば日付のフォーマットを変える処理。共通関数として1つ定義し、他はその関数を参照するべきです。しかし、共通関数を作らずに色々なクラスで同じ処理を書いていることが良くあります。
理由は担当者に分かれて開発するからだと考えられます。A機能の担当者、B機能の担当者、C機能の担当者と担当に分かれて開発します。
A機能の担当者はA機能内に関数を書き、B機能の担当者もB機能内に同じ関数を作るといったイメージです。担当者間で連携するか、開発リーダーがその辺りをケアするか、ソースレビューで指摘するなどの対策をとり同じ処理は極力無くすべきです。
最低限守りたいコーディング規約その5「コメント」
コメントはJavadoc形式でクラスとメソッドには必ず書きましょう。コメントは「簡潔」かつ「分かりやすい」のがベストです。
JavadocとはJavaのソースコードからドキュメント生成してくれる便利な機能です。javadoc形式でコメントを記載しておくと、生成されたドキュメントに説明文として記載されます。クラス名やメソッド名にJavadoc形式で説明のコメントを書いておけば、ドキュメント化した時に非常に見やすいドキュメントです。
Javadoc形式のコメントサンプル
/**
* クラスやメソッドの説明文
* @param 変数名 変数名の説明
* @return 戻り値の説明
*/まとめ
Java言語で最低限守りたいコーディング規約について紹介しました。同じ内容のソースコードでもしっかり整理されたソースコードはとても見やすいです。
開発は作成した後に保守のフェーズがあります。開発した人が保守をやるとは限りません。保守の人のことまで考えた、他の人が見ても"わかりやすくて"、"メンテナンス性が高い"ソースコードが本当の良いコードだといえるのではないでしょうか。