Javaのインスタンス変数の初期化における、コーディング規約について。


Javaのインスタンス変数の初期化における、コーディング規約を作っています。

null、0、false 以外の値で初期化する場合、初期値の記述は必要ですが、
null、0、false の初期化であっても、以下のように明示的に、
Class A {
private String x = null;
private int a = 0;
private boolean y = false;
...
}
とする、コーディング規約の方がよいでしょうか。

それとも、Java仕様では何も記述しなければ、確実に null、0、false で初期化されるため、null、0、false で初期化したいのならば、以下の方がよいでしょうか。

Class A {
private String x;
private int a;
private boolean y;
...
}

回答の条件
  • 1人1回まで
  • 13歳以上
  • 登録:2016/04/02 21:49:20
  • 終了:2016/04/09 21:50:03

ベストアンサー

id:newta No.1

newta回答回数67ベストアンサー獲得回数72016/04/02 23:13:14

ポイント150pt

コーディング規約はチームのメンバーによって変えるべきとは思っていますが
このケースでは書かない方がメジャーかなと思います。


みんなプログラミング初心者で勉強のために書いておくとか
そういうことならばあり、というくらいの認識かと思います。

実際に本番環境で動かすシステムとしてこの初期値を書く規約を適応する場合
ちょっと心配になるメンバーですね。

その他の回答(1件)

id:newta No.1

newta回答回数67ベストアンサー獲得回数72016/04/02 23:13:14ここでベストアンサー

ポイント150pt

コーディング規約はチームのメンバーによって変えるべきとは思っていますが
このケースでは書かない方がメジャーかなと思います。


みんなプログラミング初心者で勉強のために書いておくとか
そういうことならばあり、というくらいの認識かと思います。

実際に本番環境で動かすシステムとしてこの初期値を書く規約を適応する場合
ちょっと心配になるメンバーですね。

id:a-kuma3 No.2

a-kuma3回答回数4324ベストアンサー獲得回数17732016/04/08 01:52:26

ポイント150pt

コーディング規約の目的は大きく分けて三つあると思います。

  1. (低い)レベルの底上げ
  2. ソースの機械的な処理をしやすくする
  3. 何かの儀式

大抵は 1. を目的として書かれていることが多い(3. もか?)と思うのですが、質問に書かれている範囲であれば、どっちでも構わないと思います。


何かの急造プロジェクトで、とにかく人をかき集めて、プロジェクト終了後にはさようなら、というケースもありますが、長くお付き合いするかもしれない面子のレベルの底上げを目的としているならば、「とにかく、こう書いておけ」というのではなく、「こういう目的(メリット)があるから」ということも含めたコーディング規約にしておきたいものだと思います(半分は、自分向けの台詞)。


質問で対比させている二つのケースだと、どっちでもさして変わらないですが、この類のコーディング規約で本当に大切なことは、
「その変数(含む、メンバ)のデフォルト値は何が適切なんだろうか」
ということを考えましょう、ということだと思います。

プリミティブな型ではないオブジェクトの場合、null が初期値として適切でしょうか。
デフォルト値に相当するインスタンスで初期化する方が適切かもしれません。
デフォルト値に相当するインスタンスを取得するのにコストがかかるのであれば、メンバの初期値が null になっていることが大切なのではなくて、「値の取得にコストがかかる」ということを意識してもらうことのが大切です。
そのコストをトータルで下げるために、Null Object や Factory、Fly Weight などのパターンを使うのだ、とか。

プリミティブな型でも同じです。

何かのコードを意味する int なメンバであれば、明示的に初期化されてないことを表す -99999 というような変な値を初期値にするとか(有名人の誕生日とか、何かの記念日を使うことあります)。マジックナンバーを忌避するなら final な値にすれば良いとか、範囲が決まっているなら enum を使おうぜ、とか。

boolean だって、false と true のどちらが適切なのかは、そのメンバの性格によると思います。
そのインスタンスが、あるチェックを通ったかどうかを示すフラグとして、is_checked のような命名なら、安全側に倒して false で初期化すべきだとか、基本的に状態が変わらないクラスだけれど、例外的に状態が変わることがあって、is_normal のような命名なら true で初期化すべきだとか(例としては、無理やりか?)。
もちろん、命名によって、true / false のどちらが適切かは変わりますし、2値しか取らないけど boolean よりも enum や オブジェクトにする方が適切な場合もあるでしょう。


もちろん、手間はかかります。
なので、質問にあるようなどっちでも良いことは端折ります :-)
もっと大事なことの方に心血を注ぎます。


そうも行かないのが、「何かの儀式」の場合。
変数の初期化が言語の仕様として決まっていないものしか経験したことがない人が、規約のレビュアだったりとか。

そういうめんどくさいケースでは、ふたつ作ったこともありました。
ひとつは「初歩編」と題して、どこかで使った規約を流用して、明らかにおかしいところだけを手直し(手間をかけないことを最優先)。
本当に気にしてもらいたいことは、無印の本編として、実際の開発メンバーにはそっちを主体にしてプロジェクトを進める。
初歩編は、「一応、目は通して欲しいけど、当たり前のことしか書いてないよ」ってな感じで。

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません