プログラマが守るべき心得
Javaコーディング規約2003は，前半で述べたコーディングの心得5カ条とイディオム規約，それにネーミング，フォーマット，コメントに関する規約で構成されている。
最初に，コーディングの心得5カ条で定めた5つの心得を紹介する（図4[拡大表示]）。「すべて常識的なこと。私はいつも心掛けている」という人も多いかもしれないが，重要なのはそれをパートナー企業も含めた全員が徹底することだ。
1つ目の心得は，「見やすさを重視せよ」である。良いコードの基本は，「他人が読んでも分かりやすいと感じられるコード」だ。そして，コードの分かりやすさは，フォーマットはもちろん，ロジックの簡潔さやAPIの常識的な使い方から生まれる。これを意識するよう促したのが，1つ目の心得である。
2つ目は，「ネーミングは分かりやすく」。プログラマは，コーディング時に変数名やクラス名，メソッド名など，様々なネーミングを行うが，このネーミングがソースコードの可読性に大きな影響を及ぼす。例えば「int p = 5000;」という記述があったとしよう。プログラマに聞くと「変数名pは価格（Price）の略です」と言うかもしれない。しかし，そうだとすると略さずに「int price = 5000;」とした方が分かりやすい。
3つ目は，「サンプルを鵜呑みにしない」。コーディングを始めて間もないプログラマには，サンプルの意味も分からずにそのまま利用する人が多い。サンプルコードを利用することは構わないが，内容はすべて把握したうえで適用しなければならない。そうでなければ，思わぬところで障害が発生しかねない。
4つ目は「同じコードを2度書かない」である。例えば，同じコードを複数の場所にコピー・ペーストすると，異なる個所で何度も同じ修正をする羽目になりかねない。同じコードがあるならまとめて1つにし，呼び出せるようにしておくべきである。
同じコードを1つにまとめる作業は，どちらかといえば，コーディング時よりリファクタリング時に行うことが多いが，コーディング時からできるだけ気をつけておきたいことだ。
最後の心得は「役割は1つに」。例えば，メソッドの役割が1つであれば，単体テストが行いやすくなるほか，修正個所が分かりやすいために修正時間も短縮できる。例えば，「チェックする」と「実行する」という2つの役割を持つ「checkAndDo()」というメソッドは，「check()」メソッドと「do()」メソッドに分割すべきである。2つの役割を持ったままでは，「check()」メソッドのチェック・ロジックに誤りがあった場合に，「do()」メソッドまで変更しなければならないからだ。分割してあれば，「check()」メソッドのみの変更で済む。同じことは，クラスの設計にも当てはまる。
約130の規約を規定
詳細なコーディング規約としては，ネーミング規約を約30個，ネーミング以外のフォーマット，コメント，イディオムに関する規約を約100個定めている。スペースの関係ですべては掲載できないが，規約のタイトルの一部を図5[拡大表示]に示した。
ネーミング規約としてはパッケージ，クラス，テストクラス，メソッド，引数，変数などの名前の付け方を，ネーミング以外の規約としては，ソースコードのフォーマットやコメントの書き方，クラスやメソッド，変数，制御文（ifやfor，whileなど）の使い方などを定めている（図6[拡大表示]）。規約の量が多すぎると感じるかもしれないが，これでも必要な規約を厳選した結果である。
コーディング規約の内容はWordで作成している。このファイルを，Excelで作成した「コーディング規約一覧表」のファイルとセットにしてSEや品質管理者，プロジェクト・マネジャー，プログラマに配布している。規約の内容は，Excelの一覧表から簡単に参照できる仕組みにしている。具体的には，一覧表中の規約のタイトルをクリックすると，Wordが起動してその規約の詳しい説明とサンプルコードを記述したページが表示される（図7[拡大表示]）。
各規約にはインスペクション方法（目視かツールを利用するか）も明記している。プログラマがコーディング規約を遵守しているかどうかは，SEや品質管理者がソースコード・インスペクションを通じてチェックする必要があるからだ。
もっとも，1つのコーディング規約をすべてのシステム開発プロジェクトにそのまま適用するのは無理がある。例えば「例外」や「ログ出力」に関する規約は，プロジェクトごとに異なるのが普通だ。また，プロジェクトで採用するフレームワークやミドルウエアに特化したコーディング規約も存在する。
このため，Javaコーディング規約2003は，プロジェクトごとのカスタマイズを前提とした構成になっている。あるプロジェクトで規約を追加・削除する場合は，Excel上のコーディング規約一覧表で規約を追加・削除し，追加する規約の説明をフォーマットに従ってWordに記述する。ただし，Javaコーディング規約2003にもともと含まれる規約を修正するのは禁止している。標準規約はそのまま残しておかないと，どれが標準か分からなくなるからである。
図8[拡大表示]に，実際の規約例を2つ示した。上の例は「for文のカウンタは通常0からスタート」というタイトルの規約である。これまでのプロジェクトで，for文のカウンタが1から始まっていることが数回あったために，標準規約として採用した。下の例は，「forとwhileの使い分けを意識する」というタイトルの規約だ。これは，forとwhileを処理の内容に応じて使い分けることで，ロジックの可読性を向上させることを目的とした規約である。
実装工程への適用と効果
ISIDでは，Javaコーディング規約2003を次のように適用している（図9[拡大表示]）。まず，実装工程が25％程度終了した段階で，全プログラマが作成したソースコードを対象に，Java言語とJavaコーディング規約2003を十分に理解している複数のエンジニアが目視によるインスペクションを実施する。このインスペクションは，プログラマのレベルやコーディング規約の理解度を確認するのが目的である。ソースコードに規約違反が見つかった場合，インスペクションを実施したエンジニアが，その部分を担当したプログラマに規約の遵守を指導して修正を指示する。
その後は，コーディング規約に沿っているかどうかを調べるインスペクション・ツール（右ページの囲み記事参照）を使ったチェックを定期的に実施する。現状ではインスペクション・ツールでチェックしているのは，ツールが標準で持っている規約のみであるが，それでも(1)機械的にチェックできるのでチェック・ミスがない，(2)Javaに詳しくないSEでも実施できる，などメリットは多い。今後は，Javaコーディング規約2003に含まれるすべての規約のチェックをツールで自動化したいと考えている。
Javaコーディング規約2003は規約数が多いため，策定した当初は各プロジェクトで受け入れられるかどうか不安があった。しかし公開後の反響は想像していたよりもはるかに良く，現在では多くのプロジェクトで採用されている。プロジェクトごとに作成した新しい規約も徐々に増えてきている。
ISIDがJavaコーディング規約2003を導入した目的は，プログラマが規約を遵守し，それをSEや品質管理者がチェックすることで，保守性の高い良いコードを作成することである。しかし，実際に導入してみると，予想していなかった大きな効果があった。それは，プログラマに良いコードを書く「意識」が根付いたことである。自分のソースコードが品質管理者にチェックされることを意識するようになったからだ。
また，プログラマがJavaコーディング規約2003を遵守することで保守性以外の品質にも効果が表れている。例えば，スレッドや文字列，ストリームなどに関する規約を守ることでコーディング・ミスが減り，プログラム全体のバグが減少した。ソースコード・インスペクションにより，多くのコーディング・ミスを実装工程で発見できるようになったのも大きなメリットである。
業界での標準化を期待
ISIDは，来年中にもJavaコーディング規約2003を一般に公開する予定である。これにより，他社のプログラミング研修でJavaコーディング規約2003を利用してもらったり，この規約をベースにコーディング規約を標準化する動きが起こることを期待している。
Javaが普及し始めた1998～2000年頃は，Javaプログラマは「Javaが書ける」というだけで，もてはやされていた。しかし，現在では良いコードが書けるプログラマだけが求められている，といっても過言ではない。その一方で，入門書を見ながら，なんとかコードを書いているプログラマも依然として多い。入門書をマスターしたプログラマが研修でコーディング規約を学ぶようになれば，良いコードが書けるプログラマの増加につながると考えている。また，コーディング規約が業界で標準化されれば，それをチェックする機能を様々なインスペクション・ツールが標準で備えるようになるだろう。そうなれば，ソースコードのインスペクションが，今よりもずっと容易になる。
以上，コーディング規約の重要さとISIDが作成したJavaコーディング規約2003について解説してきた。Javaコーディング規約2003を公開したとしても，それが標準になるとは限らないし，この規約だけがベストと言うつもりもない。だが，少なくともJavaベースのシステム開発において，実装工程でコーディング規約を導入することが，保守性や生産性を大幅に向上させることは筆者らの経験から明らかである。本記事を参考にして，1人でも多くのエンジニアが同様な取り組みを始めれば，これに勝る喜びはない。
規約のチェックを自動化するインスペクション・ツールソースコード・インスペクションは，従来目視で行われてきた。しかし「時間がかかる」，「高レベルのインスペクションを実行できるメンバーが限られている」，「インデントのずれや改行など，低レベルな指摘が多い」，「人の目ではチェック漏れが起こりやすい」といった理由により，積極的に実施されていない状況がある。これらの問題を解決する方法として最近では，インスペクション・ツールを利用するケースが増えている。 インスペクション・ツールは，使用方法で大きく2種類に分けられる。 1つは，ソースコードの品質管理者などがソースをまとめてチェックし，レポートを出力するツール。例えば，米パラソフトの「Jtest」は，用意されている規約の種類が豊富で，規約の説明，レポート機能も充実している。既存の規約をカスタマイズしたり，新規に規約を追加したりすることもできる。ソースコードの品質管理に使いやすいツールと言える。 もう1つは，プログラマが規約に違反するコードを記述した瞬間に画面にアラートを表示するツール。フリーソフトの「CheckStyle」や「PMD」がその代表例である。いずれも，統合開発環境「Eclipse」のプラグインとしても利用できる。プログラマがその都度修正できるメリットがあるが，基本的にはユーザーが規約を定義する仕組みになっているので，その作業に手間がかかるのが難点だ。 |
|
高安 厚思（たかやす あつし）／電通国際情報サービス 事業推進本部 開発技術部テクニカルエバンジェリスト 横浜国立大学経営学部卒。銀行系シンクタンクでオブジェクト指向技術の研究に携わった後，電通国際情報サービスに入社。オブジェクト指向やJavaの技術支援／標準化に従事。アーキテクチャ，モデル，プロセスが最近の探求対象 |
|
戸田 和宏（とだ かずひろ）／電通国際情報サービス 事業推進本部 開発技術部ITアーキテクト 筑波大学大学院理工学研究科修了後，電通国際情報サービスに入社。Javaを用いたフレームワーク構築やWebシステム開発を中心とした技術支援，プロジェクト監査を行っている |
