メソッドの最後でしか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禁止」の意図にはそぐわないのではないだろうか。

　また、その手段(ルール)が目的を達成するための方法として機能しない場合、そのルールは訂正されるべきだが目的が失われてしまった場合、訂正が非情に困難になる。

　とくに「可読性」などという主観に根ざした評価軸を理由とするコーディングルール制定は、その目的を失わないように注意しなくてはいけない。