メソッドの最後でしかreturnを書いてはいけない時
柴田 芳樹 (Yoshiki Shibata):So-netブログに出てくる、「メソッドや関数の最後でしかreturn文を書いてはいけないと、プロジェクトの標準として何らかの方法で強制」された場合、機械的な書き換えを行うことで対応することが出来る。
まずは戻り値がvoidのメソッド。条件分岐などでreturnしているようなケース。
public void hoge1a(boolean b) { if (b) { System.out.println("true"); return; } else { System.out.println("false"); return; } }
これはラベル付きブロック+break文に置き換えることで単純に置換できる。
public void hoge1b(boolean b) { ret:{ if (b) { System.out.println("true"); break ret; } else { System.out.println("true"); break ret; } } }
次に戻り値を返す場合。変数宣言が加わるが基本的には一緒。
public String hoge2a(boolean b) { if (b) { return "true"; } else { return "false"; } }
public String hoge2b(boolean b) { String ret; ret:{ if (b) { ret = "true"; break ret; } else { ret = "false"; break ret; } } return ret; }
switch文などを使っている場合でも同じように対応することが出来る。
public String hoge3a(int i) { switch (i) { case 1: return "1"; case 2: return "1"; case 3: return "1"; default: return "other"; } }
public String hoge3b(int i) { String ret; ret:{ switch (i) { case 1: ret = "1"; break ret; case 2: ret = "1"; break ret; case 3: ret = "1"; break ret; default: ret = "other"; break ret; } } return ret; }
目的の失われたルール
ルールというのは本来は目的があって制定される。メソッド途中でのreturnを禁じようとした人は、どういう理由で、何を狙ってそのようなルールを定めたのか。
ルールだけを、字面通り守るのであれば、単純な書き換えで対処することができるわけだが、上記の書き換えは「メソッド途中でのreturn禁止」の意図にはそぐわないのではないだろうか。
また、その手段(ルール)が目的を達成するための方法として機能しない場合、そのルールは訂正されるべきだが目的が失われてしまった場合、訂正が非情に困難になる。
とくに「可読性」などという主観に根ざした評価軸を理由とするコーディングルール制定は、その目的を失わないように注意しなくてはいけない。