TOP
＞
設計・移行・活用
＞ 推奨されないAPIを使用しない（C_GNR001）
Javaコーディング規約
第５回：フォーマットに関するコーディング規約
著者：
電通国際情報サービス 高安 厚思、東田 健宏
インクステクニカルサービス 桐山 邦彦
2005/10/6
前のページ
1
2
3
4
次のページ
推奨されないAPIを使用しない（C_GNR001）
「推奨されない」と指定されたクラス／メソッドなどは使用しないでください。これらの機能が必要な際は、SDK Document内に示されている代替案などを参照してください。
推奨されないAPIとなっているメソッドの多くは、何らかの問題点を抱えているメソッドで、将来的には使用できなくなる可能性があります。将来のJava SDKのバージョンアップや仕様変更の際に使えなくなり、ソースコードの修正が発生することになります。推奨されないAPIとなっているメソッドには大抵代替となるメソッドが用意されていますので、必ずそちらを使ってください。
使われないコードは書かない（C_GNR002）
使われていないprivateメソッドや変数、あるいはローカル変数が存在する場合、必要ないものは削除してください。必要のあるものについては、それが使用されるようソースコードを見直してください。
この規約については、あまりにも当たり前のことを述べているように思えるかもしれません。しかし実際のプロジェクトでは、とりあえず空のメソッドだけを書いておいたまま放置されているメソッド、仕様変更によって使用されなくなったメソッドなどを最後まで残したままリリースしがちです。
使用されないメソッドが残ると無駄なリソースを消費するばかりでなく、メンテナンス時の混乱の元になることも考えられます。プログラムをリリースする前には不必要なコードが残っていないかどうかを必ず見直すようにしてください。
宣言は適切な権限で（C_GNR003）
private／publicなどのアクセス修飾子の意味を十分理解し、クラス／メソッド／変数／定数などは適切な権限で宣言するようにしてください。
メソッドや変数をすべてpublicで宣言してしまうと、クラスの内部でのみ使用することを想定した変数やメソッドを他のクラスから呼ばれてしまい、バグの発生につながる可能性があります。
変数やメソッドを宣言する際は、まずはprivateで宣言することを考えてから必要な場合のみ、適切な権限を与えるようにしてください。
finalを適切に利用する（C_GNR004）
継承されないクラスやオーバーライドされないメソッド、値の変わらない変数（つまり定数）などの変化のない（変化させたくない）ものについてはfinalで宣言するようにしてください。
変数をfinalで宣言することにより、他のクラスから不意に値を書き換えられてしまうことを防ぐことができます。またfinal宣言をすることによって値が変わらないことが明示され、コードの可読性の向上が期待できます。
クラスやメソッド、変数を宣言する際には、finalをつけるべきかどうかについて必ず考慮するようにしてください。
プリミティブ型と参照型の違いを意識する（C_GNR005）
Javaで用いられる変数は値の格納方法の違いから、プリミティブ型と参照型の2つに大きく分類されます。プリミティブ型と参照型のそれぞれの特性を把握して、適切に利用するようにしてください。
メソッドのパラメータとして渡される引数が、プリミティブ型である場合と参照型である場合の挙動の違いを理解することは重要です。引数がプリミティブ型である場合には値そのものが渡されますが、参照型の場合にはインスタンスへの参照が値として渡されます。
したがって、参照型の引数の状態をメソッド内でむやみに変更すると、複数箇所からそのインスタンスが参照されているような場合、不整合を引き起こすことがあります。この違いをはっきりと意識しながらプログラミングを行うようにしてください。
ちなみに、Java 5.0からはオートボクシング／アンボクシング機能（注1）が追加されたことにより、プリミティブ型と参照型の違いを意識する機会が少なくなることが予想されます。メモリの使用量や実行速度に加えてデフォルト値も異なりますので、それぞれの性質をしっかりと把握して適切に使いわけるようにしましょう。
※注1：
プリミティブ型（intなど）と対応するラッパー型（Integerなど）の間の変換を暗黙のうちに自動で行う機能
メトリクス
Javaコーディング規約でのメトリクスとは、ソースコードの品質を数値で定量的に表す際の測定基準を定義したものです。Javaコーディング規約には以下で示すメトリクスがあります。
文字・行字数の制限
以下のメトリクスに関する規約を見て、「厳しすぎて到底守れない」と考えた方も多いのではないでしょうか。確かに処理やプログラムの性質によっては、本規約で示すメトリクスを守れないケースがあると思います。
1メソッドの行数は約20行以下（C_MTR001）
1クラスの行数は約600行以下（C_MTR002）
1クラス内のpublicメソッド数は30個以下（C_MTR003）
1パッケージ内のクラス数は10個以下（C_MTR004）
表2：文字・行字数の制限の規約
例えば、「1メソッドの行数が21行以上の場合は絶対に分割しなければいけない」といったように杓子定規に適応してしまうと、かえってコードの可読性が落ちることがあります。
このように例外的にメトリクスの規約に適応しないケースがでてきた場合には、ソースコードレビューを実施してコードの妥当性を確認してください。そして、妥当なコードだと判断した場合は、あえてメトリクスの規約を守る必要はありません。
循環的複雑さを大きくしない（C_MTR005）
循環的複雑さとは、条件分岐や繰り返し処理によるネストの数やメソッドの呼びだしの多さによって表されるコードの複雑さのことをいいます（Googleなどの検索ページで"マッケーブの循環的複雑度"というキーワードで検索するとヒットしますので、興味のある方はぜひ調べてみてください）。
循環的複雑さが増すとコードは複雑になり、結果として可読性／保守性が低下してバグの発生につながります。これより循環的複雑さを大きくしないコードを書くようにしてください。
ちなみに、Eclipseのプラグインなどを使うと循環的複雑さを簡単に計測することができますので、ぜひ活用してみてください。
前のページ
1
2
3
4
次のページ
著者プロフィール
株式会社電通国際情報サービス 高安 厚思
株式会社電通国際情報サービス 開発技術センター
Java（J2EE）／オブジェクト指向の研究開発やプロジェクト支援、開発コンサルティングに従事。モデル、アーキテクチャ、プロセスが探求対象。今回は Javaコーディング規約2004の仕掛け人。
著者プロフィール
株式会社電通国際情報サービス 東田 健宏
株式会社電通国際情報サービス 開発技術センター
CTI、Webアプリの開発経験を経て、現在は主にプロジェクトマネジメント支援、プロセスエンジニアリング、ソフトウェア工学研究開発に従事。最近はコーチング、ファシリテーションといったヒューマン系スキルに興味を持ち日々修得に努めている。
著者プロフィール
インクステクニカルサービス株式会社 桐山 邦彦
インクステクニカルサービス株式会社 システム開発部所属
J2EEのリリース時から今日まで、主にWebアプリの開発に従事。他人から引き継いだコードのメンテナンス作業も多く、その保守性の低さをたびたび経験し、オブジェクト指向設計に強い関心を抱くようになる。
INDEX
第5回：フォーマットに関するコーディング規約
はじめに
推奨されないAPIを使用しない（C_GNR001）
インデントに関する規約
その他のフォーマットに関する規約
