methods - このシナリオでも、メソッドごとに return ステートメントは 1 つだけですか?

Question

returnメソッドごとにステートメントを 1つだけにするというアイデアが気に入っています。

この状況ですが、あなたはどうしますか？

public static string ChopText(string Text)
{
   if (String.IsNullOrEmpty(Text))
   {
      // return here ?????
   }
}

私が考えることができる唯一の代替手段は、フラグを設定してからフラグをチェックすることです。

問題は、複数のページにまたがる巨大な if ステートメントが好きではないことです。 この結果、いネストされた if ステートメントも見てきました。

score 36 · Accepted Answer

36

ネストされた条件文をガード句に置き換えても問題ありません。

于 2008-11-24T21:35:17.600 に答える

score 25 · Accepted Answer

率直に言って、このような状況が、過度に厳格なルールが良くない理由です。

このようなルールのポイントは、コードを読みやすく保守しやすくすることです。そのため、コードが読みにくくなる場合は無視する必要があります。

これは、ほとんどの場合、コードが読みやすくなるため、ルールを完全に破棄する必要があるという意味ではありません。

score 8 · Accepted Answer

関数ごとに 1 つの戻りのみを持たせようとするコードは、はるかに複雑です。通常は、if-then と代入のネズミの巣です。この種のコードを見て、これらのさまざまなパスから常に正しい値が返されていることを理解してください。とんでもない。

そうは言っても、大規模な関数は、とにかくコードをより小さく単純な関数にリファクタリングする必要があることを示しています。

score 7 · Accepted Answer

個人的に私は思います

public static string ChopText(string Text))
{
   if(String.IsNullOrEmpty(Text)
      return Text;

   ...
}

それらが気に入らなくても、それが大きくなっている場合でも、まったく問題ありません。

score 4 · Accepted Answer

これは、ルールを無視する必要がある場合です。渡された引数が正しい形式でない場合に、ArgumentException を返すかスローするメソッドへのエントリポイントにいくつかのガード句を配置するのが一般的です。これらのステートメントをメソッドの先頭にまとめておいてください。

score 4 · Accepted Answer

「メソッドごとに return ステートメントを 1 つだけにするというアイデアが気に入っています。」説明？

メソッドに渡されたパラメーターが無効であることがわかったらすぐに、例外を返すかスローする必要があります。

悪い：

if (Valid) { do lots of stuff}
else {return};

掃除：

if (invalid) { return; }
if (invalid2) {return; }

別のアプローチ:

if (invalid) {
     throws IllegalArgumentException();

score 2 · Accepted Answer

このようなことを行うことのコストと利点を実際に比較検討する必要があります。return ステートメントが 1 つしかないことの利点は、かなり単純に記述できるはずのメソッドをゆがめなければならないことの欠点を上回るでしょうか?

この場合、私はノーで行きます。

score 2 · Accepted Answer

一般的に、メソッドは「1 画面」を超えないようにする必要があります。もしそうなら、（一般的には）それらをいくつかの方法に分割するようにしてください。これはおそらく、「return ステートメントを 1 つだけ」持つことよりもはるかに重要です...

結局のところ、私たちが求めているのは読みやすさです。

score 2 · Accepted Answer

例外が設けられているため、「1 回のエントリ - 1 回の終了」というルールはもはや存在しないため、厳密な「1 回のリターンステートメント」ルールに従う必要はまったくありません。制御フローは、理論的には、例外をスローしてスタックをアンワインドすることでいつでも関数を終了できるため、厳密な「単一のエントリ - 単一の終了」ポリシーを実装したとしても、それがまったく守られるという保証はありません。

必要に応じて、いつでも関数を終了してください。

score 1 · Accepted Answer

関数の先頭で入力を検証することを除いて、私は「1 つのエントリと 1 つの出口」を強く信じています。ただし、それは関数の実際の作業が始まる前に発生する必要があります。

このルールは、実際の作業を行っているコードの途中で、「終わった」と思って人々が終了するのを防ぐためのものだと思います。

複数のリターンの問題は、ソケットのクローズや他のリソースの解放など、必要な終了処理が実行されるかどうかを確認できないことです。

score 0 · Accepted Answer

ルールは時代遅れです。簡潔でシンプル。悪いプログラマーがより読みやすいコードを書くのを助けるために存在します...そしてそれは裏目に出ました. コードを小さくて読みやすくし、そのばかげたルールを取り除きます。

score 0 · Accepted Answer

「1 つのエントリと 1 つの出口」が複雑なコードになるという考えには、私は強く反対します。約 100 個のファイルで構成される Java で Blackberry および Android 携帯電話用のアプリケーションを作成しましたが、最後に終了しないメソッドは 1 つもありません。これは GUI アプリでマルチスレッドですが、複雑なコードはありません。画面上に全体が表示されないルーチンはほとんどありません。私は 46 年間、ほんの一握りの言語とオペレーティングシステムを除くすべてのソフトウェアを設計および作成してきました。私にとって、「1 つのエントリと 1 つの出口」は、非常にシンプルで読みやすく、保守しやすいコードを実現します。私の0.02ドルの価値。羽をフリルした場合は申し訳ありません。

methods - このシナリオでも、メソッドごとに return ステートメントは 1 つだけですか?

13 に答える 13

Related

Reference