このシナリオでも、メソッドごとに1つのreturnステートメントだけですか?
質問
メソッドごとに return
ステートメントを1つだけにするというアイデアが好きです。
この状況で何をしますか?
public static string ChopText(string Text)
{
if (String.IsNullOrEmpty(Text))
{
// return here ?????
}
}
考えられる唯一の選択肢は、フラグを設定してからフラグをチェックすることです。
問題は、1ページ以上にまたがる巨大なif文が嫌いです。この結果として、nestedいネストされたif文も見たことがあります。
他のヒント
率直に言って、このような状況は過度に厳格なルールが悪い理由です。
このようなルールのポイントは、コードをより読みやすく、保守しやすくすることです。したがって、コードを読みにくくする場合は無視する必要があります。
これは、ほとんどの場合コードを読みやすくするため、ルールを完全に破棄する必要があるという意味ではありません。
関数ごとに1つの戻り値のみを取得しようとするコードは、はるかに複雑です。通常、if-thenと代入のネズミの巣です。そのようなコードを見て、それらの異なるパスから常に正しい値が返されることを知ってもらうように挑戦します。まさか。
とはいえ、大きな関数は、コードを小さな単純な関数にリファクタリングする必要があるかもしれないことを示しています。
個人的には
public static string ChopText(string Text))
{
if(String.IsNullOrEmpty(Text)
return Text;
...
}
それらが気に入らない場合、および大きくなっている場合は、まったく問題ありません。
"メソッドごとにreturnステートメントを1つだけにするというアイデアが好きです。"説明してください
メソッドに渡されたパラメーターが無効であることがわかったらすぐに、例外を返すかスローする必要があります。
悪い:
if (Valid) { do lots of stuff}
else {return};
クリーン:
if (invalid) { return; }
if (invalid2) {return; }
別のアプローチ:
if (invalid) {
throws IllegalArgumentException();
これは、ルールを無視する必要がある場合です。メソッドへのエントリポイントには、渡された引数が正しい形式でない場合にArgumentExceptionを返すかスローするいくつかのガード句が一般的です。メソッドの最初にこれらのステートメントをまとめておくだけです。
あなたは本当にこのようなことをすることのコストと利益を比較検討しなければなりません。 returnステートメントを1つだけ持つことの利点は、作成するのがかなり簡単なメソッドをゆがめる必要があるというマイナス面を上回りますか?
この場合はいいえで行きます。
例外が存在する場合、「単一エントリ-単一出口」はありません。とにかくこれ以上ルールを適用しないため、厳密な「1つのreturnステートメント」に従う必要はまったくありません。ルール。制御フローは、理論的には、例外をスローしてスタックをアンワインドすることにより、いつでも関数を終了できます。ポリシーに準拠するという保証は一切ありません。
必要に応じて、いつでも関数を終了してください!
メソッドは、一般的に「1画面」を超えないようにする必要があります。そうした場合は、(一般的に)いくつかの方法に分割してみてください。これは、おそらく「1つのreturnステートメントのみ」を使用するよりもはるかに重要です...
結局のところ、私たちが探しているのは読みやすさです。
「最上位の入力を検証することを除いて、「1つのエントリ/ 1つの出口」を強く信じています。ただし、関数の実際の作業が始まる前に発生する必要があります。
このルールは、単に「やった」と思っているからといって、実際の作業を行っているコードの途中でユーザーが終了するのを防ぐことを意図したものだと思います。
複数の戻り値の問題は、ソケットのクローズや他のリソースの解放など、必要な終了処理が実行されるかどうかを確認できないことです。
public static string ChopText(string Text)
{
string returnString = "";
if(String.IsNullOrEmpty(Text))
{
returnString = "return string text";
}
return returnString;
}
ルールは時代遅れです。簡潔でシンプル。それは、悪いプログラマーがより読みやすいコードを書くのを助けるために存在します...そしてそれは裏目に出ました。コードを小さく読みやすくし、その愚かなルールを取り除きます。
「1つの入口と1つの出口」という考えに強く反対します。複雑なコードになります。約100個のファイルで構成されるBlackberryとAndroidの携帯電話用のアプリケーションをJavaで作成しましたが、最後に終了しない単一のメソッドはありません。それはGUIアプリであり、マルチスレッドですが、コードはどれも複雑ではありません。画面にルーチン全体が表示されない場合はほとんどありません。私は46年間、ほんの一握りの言語とオペレーティングシステムを除いてソフトウェアの設計と作成を行ってきました。コードを非常にシンプルで読みやすく、保守しやすくします。私の0.02ドル相当。羽をフリルでしたら申し訳ありません。