第5回：フォーマットに関するコーディング規約 (1/4)

Javaコーディング規約
第５回：フォーマットに関するコーディング規約
著者：	電通国際情報サービス高安厚思、東田健宏
	インクステクニカルサービス桐山邦彦 2005/10/6

1 2 3 4 次のページ

はじめに

前回まではネーミング規約について説明してきましたが、今回からはコーディング規約について説明していきます。

皆さんが経験してきたプロジェクトにはコーディング規約が存在していましたか。存在しなかった場合には、次のようなことに対して悩んで無駄な時間を費やしてしまった経験はないでしょうか。

1行が長い場合はどの位置で改行すればよいのか？
どこまでコメントを書けばよいのか？

表1：コーディングの悩み所

今回はこのような悩みを解決するために、コーディングに関する規約の内容を説明していきます。また、設計方法に関わるような少し高度な規約も入っていますので、今後の設計を行う際のヒントとして役立ててください。

本連載で紹介する規約に関しては、規約名のみを記述しています。規約そのものは、以下のURLからダウンロードして確認してください。 http://www.objectclub.jp/community/codingstandard/JavaCodingStandard2004.pdf

全般

ここでは、コーディングするうえで基本となる規約について説明します。当たり前と思うこともありますが、実際のプロジェクトでは守られていない場合があります。ネーミング規約でもそうでしたが、規約を守ることは可読性をあげるだけではなく、バグを減らし、修正を容易にします。

オブジェクトの参照にはインターフェースを利用せよ（C_GNR000）

   オブジェクトを参照する際は、そのオブジェクトの実装クラスを用いて宣言できます。しかし、実装クラスに適切なインターフェースが存在している場合は、必ずインターフェースを用いて宣言してください。

   この規約は本連載で紹介するすべてのコーディング規約の中でも、もっともわかりにくい規約の1つかもしれません。では、実装クラスをコードに書き込むことによってどのような不都合が生じるのでしょうか。

   例えば、プログラムの中で変数や引数をすべて"ArrayList"で宣言したと考えます。このプログラムが完成した後で、実行速度の向上のために"ArrayList"を利用していた箇所のいくつかを"LinkedList"クラスに変更することが必要になるかもしれません。このような場合には"ArrayList"クラスで宣言している変数や引数をすべて探しだし、その都度"LinkedList"クラスに変更するかどうかをチェックしなくてはなりません。

悪い例（ArrayListで宣言した場合）


		import java.util.*;


		public class BadSample {

		  public static void main(String[] args){

		    ArrayList sampleList = new ArrayList(); // 違反

		    BadSample badSample = new BadSample();

		    badSample.badMethod(sampleList);

		  }


		  private void badMethod(ArrayList input){

		     //違反:呼びだし元の実装クラスがLinkedListクラスに変更されると、このメソッドも変更しなければならない。

		  }

		}

良い例（Listで宣言した場合）


		import java.util.*;


		public class FixedSample {

		  public static void main(String[] args){

		    List sampleList = new ArrayList (); //修正済み

		    FixedSample fixedSample = new

		    FixedSample();

		    fixedSample.fixedMethod(sampleList);

		  }


		  private void fixedMethod(List input){

		    //修正済み:呼び出し元の実装クラスがLinkedList クラスに変更されても、このメソッドは変更しなくてよい。

		  }

		}

   もし実装クラスである"ArrayList"のかわりに、"List"インターフェースで宣言していれば、変更に関する手間を減らすことが可能になります。

   このように、オブジェクトの参照にインターフェースを利用せずに実装クラスを直接書いてしまうと、実装の変更に影響をきたします。よって、オブジェクトの参照にはインターフェースを利用するようにしてください。

   なお、第2回「コーディングレベルを上げるためには？」のレベル5のサンプルでは、インターフェースを導入することによってプログラムの柔軟性／拡張性を向上させていました。Javaにおいて仕様変更に強いコードを実装するには、インターフェースが非常に重要な役割を果たしていることがわかるかと思います。

1 2 3 4 次のページ

参考文献など
Javaコーディング規約2004は以下のサイトおよび書籍として発表しています。本連載と共に参考にしてください。

「Javaコーディング規約2004」 http://www.objectclub.jp/community/codingstandard/JavaCodingStandard2004.pdf

「オブジェクト倶楽部」
Javaコーディング規約2004は、オブジェクト倶楽部で公開して頂いております。 http://www.objectclub.jp/

「超図解 Java ルールブック」
Javaコーディング規約が「超図解 Java ルールブック」という名前で書籍になりました。規約の詳しい内容に関しては本書籍をご覧ください。
http://www.x-media.co.jp/xbook/index.cfm?ID=6

Javaコーディング規約を理解するに際しての参考サイトをご紹介します。

「Code Conventions for the Java Programming Language」 http://java.sun.com/docs/codeconv/
※日本語訳を提供しているページ http://www.tcct.zaq.ne.jp/ayato/programming/java/codeconv_jp/

Java コーディング規約を理解するに際しての参考書籍をご紹介します。

「Java の格言」
「Java の鉄則」
「リファクタリング - プログラミングの体質改善テクニック」
「The Elements of Java Style」
「Effective Java - プログラミング言語ガイド」
「Essential Java Style」

	著者プロフィール株式会社電通国際情報サービス高安厚思株式会社電通国際情報サービス開発技術センター Java（J2EE）／オブジェクト指向の研究開発やプロジェクト支援、開発コンサルティングに従事。モデル、アーキテクチャ、プロセスが探求対象。今回は Javaコーディング規約2004の仕掛け人。
	著者プロフィール株式会社電通国際情報サービス東田健宏株式会社電通国際情報サービス開発技術センター CTI、Webアプリの開発経験を経て、現在は主にプロジェクトマネジメント支援、プロセスエンジニアリング、ソフトウェア工学研究開発に従事。最近はコーチング、ファシリテーションといったヒューマン系スキルに興味を持ち日々修得に努めている。
	著者プロフィールインクステクニカルサービス株式会社桐山邦彦インクステクニカルサービス株式会社システム開発部所属 J2EEのリリース時から今日まで、主にWebアプリの開発に従事。他人から引き継いだコードのメンテナンス作業も多く、その保守性の低さをたびたび経験し、オブジェクト指向設計に強い関心を抱くようになる。

INDEX
第5回：フォーマットに関するコーディング規約
	はじめに
	推奨されないAPIを使用しない（C_GNR001）
	インデントに関する規約
	その他のフォーマットに関する規約

Javaコーディング規約
第1回	良いコードとは、心得5ヶ条
第2回	コーディングレベルを上げるためには？
第3回	ネーミング規約（前編）
第4回	ネーミング規約（後編）
第5回	フォーマットに関するコーディング規約
第6回	オブジェクト指向のためのコーディング規約
第7回	変数に関するコーディング規約
第8回	文字操作・数値・日付に関するコーディング規約
第9回	継承とインスタンスに関わるコーディング規約
第10回	制御構造に関する規約
第11回	コレクション・ストリーム・例外に関するコーディング規約
第12回	スレッド・ガベージコレクションに関するコーディング規約