 |
|
|
| 1 2 3 次のページ
|
|
| 前回より
|
前回から引き続き、ネーミング規約について説明をします。今回はメソッド、引数、変数全般、ローカル変数についての説明です。
|
本連載で紹介する規約に関しては、規約名のみを記述しています。規約そのものは、以下のURLからダウンロードして確認して下さい。
http://www.objectclub.jp/community/codingstandard/JavaCodingStandard2004.pdf
|
|
| メソッド
|
メソッド名をつけるときには、パッケージやクラスのネーミング規則と混合しない形のネーミング規則を設ける必要があります。また、メソッドの役割を名前に反映し、名前を見ただけでそのメソッドの意味がわかるようにするべきです。
|
| コンストラクタと同じ名前のメソッドはつくらない（N_MTD001）
|
コンストラクタはその名前自身が役割を表す特殊なメソッドです。クラスと同じ名前のメソッドがあれば、大抵の人はコンストラクタだと推測してしまいます。このような誤解を招くネーミングは避けるべきです。
|
| メソッド名は区切りのみ大文字にする（N_MTD002）
|
メソッド名が1つの単語の場合はすべて小文字で記述して下さい。メソッド名が複数の単語で構成されている場合は、2語目以降の単語の先頭を大文字にして下さい。これはJavaの一般的なルールです。
メソッド名の先頭を小文字にすることにより、先頭が大文字であるクラスと明確に区別できます。また、単語の先頭を大文字にすることにより、区切り文字を使わないため、クラスとの境界の".（ピリオド）"が明確になります。パッケージ・クラス・メソッドを続けて書いてみると、この規約の効果がよくわかります。
|
java.sample.package.SampleClass.sampleMethod();
|
|
- パッケージ名はすべて小文字
- クラス名は単語の先頭のみ大文字
- メソッド名の先頭は小文字。2語目以降の単語の先頭のみ大文字
|
表1：メソッド名のネーミング規約
|
大文字／小文字の表記は習慣によるところが多く、この組み合わせが絶対ということはありません。なかには違う方法をとっているプロジェクトもあるでしょう。
大事なことはプロジェクトで統一をとることです。パッケージを作成するチームとクラスを作成するチームが、別々の規約にのっとっていては効果を発揮できません。既存のルールに合わせて、読みやすい形をとって下さい。但し、開発したシステムのライフサイクルを配慮すると一般的なルールは最低限したがっておくことでプロジェクトの参加者の出入りに対しても対応することができるでしょう。
|
| 役割を表す名前に規則性を持たせる（N_MTD003〜N_MTD006）
|
「N_MTD003〜N_MTD006」の規約は、メソッドの役割をメソッド名から推測できるようにするための規約です。「役割を表す名前に規則性を持たせる」ことの効果は前回のはクラスの項でも紹介しました。形式を統一することによってソースコードの可読性が高まり、役割からメソッドを検索することも容易に行えます。
例えば"getName"というメソッドがあれば、コードを見るまでもなく「名前を取得する」メソッドだということがわかります。また、"set〜"ではじまるメソッドを検索すれば、そのクラスのセッターメソッドはすべて網羅できることになります。
このようにネーミング規約を守ることで、メンテナンス時の作業効率をあげることもできるのです。
|
| boolean変数を返すメソッド名はtrue／falseの状態がわかるようにする（N_MTD007）
|
boolean変数を返すメソッドには、その返り値がtrue／falseのどちらでも、どのような状態になるかが明らかにわかる名前をつけて下さい。
例えば、以下のような例があげられます。
|
public boolean isAsleep(){
}
public boolean canSpeak(){
}
public boolean hasExpired(){
}
|
|
どのメソッドも、true／falseによる状態の違いがはっきりわかると思います。
ちなみに、この規約は経験則から作成されました。例えば、"checkAsleep()"というメソッドがあったらどうでしょうか。チェックした結果がAsleepであった場合、trueと判断するかfalseと判断するかは、人や状況によって変わってきてしまいます。
メソッド名を"isAsleep"にしておけば、誤解によって返り値の判定を逆にしてしまうような失敗が防げます。
メソッドには返り値を推測しやすい名前をつけて下さい。
|
| 英語の対義語を意識せよ（N_MTD008）
|
英語の対義語を意識することは、クラスの利用者の利便性を高めます。sendとreceive、topとbottomなどの対になるメソッドは、対であることがわかるように、常に同じ組み合わせで命名しておくと便利です。
メソッドによって、対義語になっていなかったらどうでしょうか。お互いが対になっていることを理解することが難しいでしょう。
"sendName"と対になるメソッドは"receiveName"となるはずですが、これが"catchName"であったりしたら、混乱の元です。
表記を統一することは、可読性の向上に繋がります。
|
1 2 3 次のページ
|
|
|
|
|
|
著者プロフィール
株式会社電通国際情報サービス 高安 厚思
株式会社電通国際情報サービス 開発技術センター
Java（J2EE）／オブジェクト指向の研究開発やプロジェクト支援、開発コンサルティングに従事。モデル、アーキテクチャ、プロセスが探求対象。今回は Javaコーディング規約2004の仕掛け人。
|
|
著者プロフィール
株式会社電通国際情報サービス 東田 健宏
株式会社電通国際情報サービス 開発技術センター
CTI、Webアプリの開発経験を経て、現在は主にプロジェクトマネジメント支援、プロセスエンジニアリング、ソフトウェア工学研究開発に従事。最近はコーチング、ファシリテーションといったヒューマン系スキルに興味を持ち日々修得に努めている。
|
|
著者プロフィール
アイエックス・ナレッジ株式会社 河野 弥恵
アイエックス・ナレッジ株式会社 第1事業部所属
主にCOBOL、PL/1等のシステム開発に従事。コーディングに限らず、誰もが気持ちよく守れる規約を模索中。
|
|
|
|
|
|
