Javaのコーディング規約【プログラミング初心者向け教材】

プログラミングには様々なお作法や暗黙的なルール、パターンがあります。

プログラムの命名規則やフォーマットなどについてのお作法やルールをまとめたものがコーディング規約です。

ルールを知らないと他人から正しくコードを読んでもらえなかったり、チーム内で自分だけ違う書き方をしてしまうということになります。

コーディング規約は基本的に組織やチーム毎に内容を決めて作成しますが、多くの場合は元にしているものがあります。

そこで本記事では、Javaでよく使われる一般的なコーディング規約についてまとめます。

ある程度一人でプログラミングができるようになった方や、組織やチームにまだコーディング規約がない方は、参考にしていただければと思います。

Javaのコーディング規約

Javaのコーディング規約のまとめとして、以下の内容を採り上げます。

コーディング規約の種類
命名に関する規約
フォーマットやレイアウトに関する規約
コメントに関する規約
その他の推奨事項

コーディング規約の種類

Javaのコーディング規約は、代表的なものとして以下があげられます。

Code Conventions for the Java Programming Language [英語] [日本語]
- 当時Javaを開発していたSun Microsystemsが作成したコーディング規約です。おそらくJavaの最初のコーディング規約だと思います。

オブジェクト倶楽部版 Javaコーディング標準 [日本語]
- 永和システムマネジメントが運営しているオブジェクト倶楽部が作成したコーディング規約です。
電通国際情報際サービス版 Javaコーディング規約2004 [日本語]
- 電通国際情報サービスが作成したコーディング規約です。
Google Java Style [英語] [日本語]
- Google社が作成したコーディング規約です。

本記事では、比較的新しいコーディング規約である『Google Java Style』の内容をまとめます。

命名に関する規約

命名	規則	例
パッケージ名	すべて小文字で連続する単語をそのまま繋げる。アンダースコアは使わない。	mypackage
クラス名	パスカルケース（アッパーキャメルケース）とする。・クラス名は名詞か名詞句とする。・インターフェース名も名詞か名詞句が基本であるが、場合によっては形容詞や形容詞句になる。・テストクラスはテスト対象クラス名で始まり、Testで終わるようにする。	MyClass ImmutableList Readable HashTest
メソッド名	キャメルケースとする。・メソッド名は動詞か動詞句とする・アンダースコアはJUnitのメソッド名でテスト内容が分かりやすいように分割するために使っても良い。	myMethod testPop_emptyStack
定数名	スネークケース（大文字のみ）とする。・名詞か名詞句とする。	MY_CONSTANT
フィールド名	キャメルケースとする。・名詞か名詞句とする。	myFieldVar
パラメータ名	キャメルケースとする。・一文字のパラメータ名はpublicメソッドでは避けたほうがよい。	myParameter
ローカル変数名	キャメルケースとする。	myLocalVar
型変数名	一つの大文字アルファベットか、それに1個の数字。クラスの命名の後ろに、大文字Tを付加する。	T T2 MyClassT

キャメルケースの定義

HTTPやXML、iOSなど、大文字を含む単語として、一般的に認識されている単語であっても、以下のように変換します。

Http（先頭単語の場合はhttp）
Xml（先頭単語の場合はxml）
Ios（先頭単語の場合はios）

フォーマットやレイアウトに関する規約

ソースファイルの構造

ソースファイルの内容は、以下の順序で記述します。

ライセンスあるいはコピーライトの情報
package文
import文
１個のトップレベルクラス

それぞれの分離には１行の空行を使います。

パッケージ文

パッケージ文は、改行しません。

インポート文

ワイルドカードを使ったインポート文は、staticであってもなくても使いません。
インポート文は、改行しません。
staticインポート、非staticインポートの順番で並べる。両方ある場合は、空行で分離します。
インポート分はASCII順で並べます。

クラス宣言

クラスのメンバー順に明確な規則はないが、ルールを決めておきます（最後に追加されていくことを慣例としない）。
オーバーロードしているメソッド群は連続して並べます。

中括弧

中括弧 {} は、if、else、for、do、while文において、本体が空や１行しかなくても使うようにします。
中括弧前後の改行は、以下のとおりとします。

開始中括弧の前 → 改行を入れない。
開始中括弧の後 → 改行を入れる。
終了中括弧の前 → 改行を入れる。
終了中括弧の後 → 文やメソッドの本体を終える場合は、改行を入れる。elseやカンマが続く場合は改行しない。

return () -> {
  while (condition()) {
    method();
  }
};

return new MyClass() {
  @Override public void method() {
    if (condition()) {
      try {
        something();
      } catch (ProblemException e) {
        recover();
      }
    } else if (otherCondition()) {
      somethingElse();
    } else {
      lastThing();
    }
  }
};

インデント

ブロックのインデントは空白２個とします。

１行の文字数制限

１行の文字数制限は100文字とします。

行の折り返し

以下のルールで折返します。

代入でない演算子で改行する時は、シンボルの前で改行する。ドット演算子やメソッド参照でのコロン2個などにも適用される。
代入演算子で改行する時は、シンボルの後ろで改行する。
メソッドやコンストラクタ名に続く開始括弧の直後で改行する。
カンマの直後で改行する。
ラムダの矢印の後にブロックが始まる場合は、開始中括弧の後で改行する。

折り返した続きの行は、少なくとも空白4個分を元からインデントします。

空白

以下の場合に、一つ空行（垂直の空白）を入れます。

クラス内の連続するメンバ変数や初期化子、コンストラクタ、メソッドの間。
処理の間で、コードを論理的にグループ分けしたい場合。
クラスの最初と最後（推奨も禁止もしない）

以下の場合に、一つの空白（水平の空白）を入れます。

予約語（if、for、catchなど）の後にくる開始括弧 ( の間。
予約語（else、catchなど）の前にくる終了中括弧 } の間。
開始中括弧 { の前。
二項演算子（=など）、三項演算子（:など）の両側。
カンマ、コロン、キャストの閉じ括弧の後ろ。
行末コメントを開始するスラッシュ2個の両側。
型と変数の宣言の間。
配列初期化子の両括弧の中。（任意）

型名や変数名の水平位置揃えは、許容するが要求もしません。
可読性はあげるが、将来のメンテナンスにおいて手間となる可能性があります。

変数宣言

変数宣言は、1回に付きに1個とします。
ローカル変数は、先頭でまとめて宣言するのではなく、必要なときに宣言します。スコープが最小化され、見通しがよくなります。

コメントに関する規約

ブロックコメント

処理中のブロックコメントは、周りのコードと同じレベルでインデントします。
/* … */ コメントについては、*の位置を前行の*と同じインデントに揃えます。

/*
 * コメント
 * コメント
 */

// コメント
// コメント

/* コメント
 * コメント */

アスタリスクや他の文字で描かれた箱で囲わないでください。

Javadocコメント

Javadocブロックは、要約の記述から書き始めます。
Javadocの記述は、少なくともpublicなクラスのクラスコメントと、publicおよびprotectedなメンバーに記述します。
getXXXのようなXXXを返すことが明確なメソッドの場合は、コメントは必須ではありません。

その他の推奨事項

@Overrideアノテーションを適用可能である場合は常に使うようにします。
捕捉した例外は無視して握りつぶすようなことをしないでください。本当に無視するのであれば、その理由をコメントで説明してください。
staticなメンバーを参照する場合は、クラス名を使ってください。変数や式経由で使わないようにします。

Foo aFoo = ...;
Foo.aStaticMethod(); // 良い
aFoo.aStaticMethod(); // 悪い
somethingThatYieldsAFoo().aStaticMethod(); // とても悪い

Objectクラスのfinalizeメソッドは使わないでください。

ツールを使って自動的にチェックできるようにしよう

コーディング規約は、多くの場合、プロジェクトや組織ごとに異なります。

それらをすべて覚えてプログラミングするのは、返って効率が悪くなる場合があるので、主要な部分は覚えて、細かい部分はツールでチェックできるようにすると良いです。

IDEにツールが備わっている場合もありますし、それぞれのコーディング規約に沿ったチェックツールが提供されている場合もあります。

それらを上手く活用し、自分たち向けにカスタマイズして、誰もが同じ規約のもとで、同じようにコードが書けるようにするのがベターです。

Javaについては、より実践的なコーディング規約や、やらない方が良いことなどをまとめた書籍がたくさんあります。

代表的なものを紹介しますので、気になる方はチェックしてみてください。

Javaルールブック読みやすく効率的なコードの原則 [ 大谷晋平 ]

楽天ブックス

￥ 2,838（2024/01/31 10:14時点）

実践Javaコーディング作法プロが知るべき、112の規約と21の心得 [ 森崎雅稔 ]

楽天ブックス

￥ 2,530（2024/01/31 11:34時点）

また、当ブログでも以前に紹介したリーダブルコードも、お作法について学べるおすすめの本です。

エンジニアのおすすめ本『リーダブルコード』

ある程度一人でプログラミングができるようになってさらに上達したい方、チームメンバーから褒めてもらえるようなより良いプログラムを書きたいと思っている方、チームで開発しているプログラムが統一感がなく属人的になっていることに悩んでいる方向けに、書籍『リーダブルコード』を紹介します。

今回はJavaのコーディング規約について紹介しました。

参考になれば幸いです。