【Java】その条件分岐は必要？その変数は必要？

職場でコーディングをしていてふと思いました。

この変数って定義する必要があるのかなあ・・・。
定義しなくても書けるし、かと言って定義した方が何回か使いまわせる。

今回はそんな必要か必要じゃないかの判断に迷う場合について考えてみます。

必要かどうかの判断に迷う状態とは？

まず私が判断に迷う状態。

例えばこんな時です。

ソース

String[] array = new String[] { "A", "B," };

if (array.length > 0) {
	for (String s : array) {
		// 処理
	}
}

for文に入る前のif文ですね。
配列のサイズが0よりも大きければループを行う条件になっています。
一見すると理にかなっているような気もしますが、実際のところこの条件が無くてもちゃんと動きます。

変数の場合はこんな時に迷っちゃいます。

ソース

Student student = new Student("Taro", 1);

String name = student.getName();

if (null != name) {
	String str = name;
}

Studentクラスは内容の内容は省きますが、よくあるBeanのクラスです。
String型のnameとint型のidをプライベートなフィールドに持ち、ゲッターセッターが備わったやつ。
そこから、nameを一度変数に代入し、以後はその変数を条件の判定し使ったり処理に使ったりします。

ゲッター程度なら、毎回ゲッター呼んでもいいような気がしちゃいます。

私個人の考え

極論で言うと、プログラムは動けば良いのです。
プログラムが正常に動いている以上それは正解。

ただし、メンテナンスのコストとか他の人が目にする場合は可読性を少しでも高める必要があります。
基本的に会社で開発を行う場合はほとんど可読性も求められるでしょう。

以上のことから、結局は正解は時と場合によるし、これが正しいという決まりはないと思います。

でも強いて言えば、自分だけが目にするソースだとしても可読性が高いに越したことはありません。
ですので、そう言った意味では常に読みやすいコードを記述したいですよね。

基本的には、ソースは短い方がコンパクトで読みやすいと言えると思います。
しかし無理やりステップ数を減らすよりは、冗長に感じても書いておいた方が良いif文や変数もあるでしょう。
そのあたりは経験とかコーディング規約を神様にして書いていくしかないです。

それを踏まえて、先ほどの判断に迷うソースをもう一度見直して記述してみます。

判断に迷ったらこんな感じで落ち着いた

まずは最初のif文の例。

配列に対しサイズを見てからfor文で回すのは、私は不要だと思います。
サイズが0より大きければ回す場合はですけど。

ソース

String[] array = new String[] { "A", "B," };

for (String s : array) {
	// 処理
}

この状態で意味は伝わるんじゃないかなと思います。
for文の仕組み上、サイズがもし0だったとしても例外は投げませんし、1回もループせずに次の処理に移ります。

そして変数の場合。
これは結構判断が難しいですね。

今回の場合はゲッターで代入して使い回しているので、ぎりぎり不要かなと思います。

ソース

Student student = new Student("Taro", 1);

if (null != student.getName()) {
	String str = student.getName();
}

クラスの変数自体はstudentとして定義していますし、それを使ってゲッターを呼ぶのであれば毎回呼んでも良さそう。
でも、その後も4回、5回と使うなら変数に保持するのもアリかな・・・
2回や3回使う程度ならゲッターで済ましてしまうと思います。

変数に保持しない理由としては、ゲッターはメンバ変数をただ引っ張ってくるだけの処理だからです。
パッと見ても「ああ、これはクラスの中のフィールドを取り出しているだけなんだろうな。」と予測が付きますし、メソッドの処理もメンバ変数のreturnだけ。
それなら何回か使用されていても別に良いんじゃないかなという考えです。

ただし、処理が複雑なメソッドの戻り値の場合は変数に代入しておくことを薦めます。
理由はずばり、その方がわかりやすいと思うからです。

処理が複雑なメソッドを何回も呼び出すと、そのメソッドの処理を追う機会が多くなります。
呼び出す度に処理を追っていては、ソースの全貌を把握するのも時間がかかってしまいます。
多分処理的にも、同じ戻り値を扱うなら変数に格納して使った方が処理速度は早いはず。

迷わないためにもブレないルールを決める

開発には時間が付き物。
設計に時間をかけてしまうと、開発工程の工数が削られてしまう場合もあります。
そんな時にちょっとした迷いで時間を割くのはなるべく避けたいですよね。

なので、自分の中のコーディング規約をある程度決めておくと良いと思います。

その日その日で思いのままにコーディングをしてしまうと、どうしても仕上がったソースに統一感が無かったり。

ちょっと趣旨はずれますが、コメントを記述する「//」のあとに半角スペースを入れたり入れなかったりするのを統一するだけでもかなり綺麗に見えますよ。
ちなみに私は半角スペース入れる派です。

それはそうと、途中にも書きましたがプログラムなんて動いていればOKという考え方もあります。
あまり深くは考えず、自分なりの綺麗を目指しても良いのではないでしょうか。

どんどんコーディングをしていくうちに自分の定型が見つかると思います。
そしていろんな人のソースを見る。これ大事。
そこから得られるものってかなりあります。

お手本をする人を探して真似しちゃうのも全然アリ。
私は結構人のをパクっちゃうタイプなので、職場ではソースを眺めている時間が長かったりします。
そこから自分のルールを作り、この時はこう書く！と決めておくと良いと思います。