関数から早く戻るか、ifステートメントを使用する必要がありますか？[閉まっている]

私はよくこの種の関数を両方の形式で記述しましたが、ある形式が別の形式よりも好まれるのか、そしてその理由は疑問でした。

public void SomeFunction(bool someCondition)
{
    if (someCondition)
    {
        // Do Something
    }
}

または

public void SomeFunction(bool someCondition)
{
    if (!someCondition)
        return;

    // Do Something
}

それはコーディング中の私の脳の働きであるため、私は通常最初のものでコーディングしますが、エラー処理をすぐに処理し、読みやすいので2番目のものを好むと思います

私は2番目のスタイルが好きです。最初に無効なケースを取得し、必要に応じて単に終了するか例外を発生させ、そこに空白行を入れてから、メソッドの「実際の」本体を追加します。読みやすいと思います。

間違いなく後者。前者は今のところ悪く見えませんが、より複雑なコードを取得するとき、誰もこれを考えるとは想像できません：

public int SomeFunction(bool cond1, string name, int value, AuthInfo perms)
{
    int retval = SUCCESS;
    if (someCondition)
    {
        if (name != null && name != "")
        {
            if (value != 0)
            {
                if (perms.allow(name)
                {
                    // Do Something
                }
                else
                {
                    reval = PERM_DENY;
                }
            }
            else
            {
                retval = BAD_VALUE;
            }
        }
        else
        {
            retval = BAD_NAME;
        }
    }
    else
    {
        retval = BAD_COND;
    }
    return retval;
}

より読みやすい

public int SomeFunction(bool cond1, string name, int value, AuthInfo perms)
{
    if (!someCondition)
        return BAD_COND;

    if (name == null || name == "")
        return BAD_NAME;

    if (value == 0)
        return BAD_VALUE;

    if (!perms.allow(name))
        return PERM_DENY;

    // Do something
    return SUCCESS;
}

単一の出口点の利点を理解したことはありません。

それは依存します -一般に、私は早く関数の外に抜け出すためにたくさんのコードを移動しようとするつもりはありません-コンパイラは通常私のためにそれを処理します。ただし、必要な基本パラメーターが上部にあり、それ以外の場合は続行できない場合は、早めにブレークアウトします。同様に、if機能が機能で巨大なブロックを生成する場合、その結果として早期にブレークアウトします。

ただし、関数が呼び出されたときにデータが必要な場合、通常は単に返すのではなく、例外をスローします（例を参照）。

public int myFunction(string parameterOne, string parameterTwo) {
  // Can't work without a value
  if (string.IsNullOrEmpty(parameterOne)) {
    throw new ArgumentNullException("parameterOne");
  } 
  if (string.IsNullOrEmpty(parameterTwo)) {
    throw new ArgumentNullException("parameterTwo");
  }

  // ...      
  // Do some work
  // ...

  return value;
}

私は早期復帰を好む。

1つのエントリポイントと1つの出口ポイントがある場合は、常に頭のコード全体を出口ポイントまで追跡する必要があります（以下のコードの一部が結果に対して他の処理を行うかどうかはわかりませんので、存在するまで追跡する必要があります）。どのブランチが最終結果を決定するかは関係ありません。これに従うのは難しいです。

1つのエントリと複数のエントリが存在する場合、結果が得られたときに戻りますが、最後まで追跡してわざわざ他の操作を行っていないことを確認します（返されてから他に何も行われないため）。メソッド本体を複数のステップに分割するようなもので、各ステップで結果を返すか、次のステップで運を試すことができます。

手動でクリーンアップする必要があるCプログラミングでは、ワンポイントリターンについて多くのことが言われます。今すぐ何かをクリーンアップする必要がない場合でも、誰かがあなたの関数を編集し、何かを割り当て、戻る前にクリーンアップする必要があるかもしれません。それが起こると、すべてのreturnステートメントを調べる悪夢のような仕事になります。

C ++プログラミングでは、デストラクタがあり、スコープ出口ガードさえあります。コードがそもそも例外安全であることを保証するためにこれらすべてがここにある必要があるので、コードは早期終了に対して十分に保護されているため、そうすることは論理的なマイナス面を持たず、純粋にスタイルの問題です。

「最終的に」ブロックコードが呼び出されるかどうか、ファイナライザーが何かを確実に行う必要がある状況に対処できるかどうか、Javaについて十分な知識がありません。

C＃私は確かに答えられません。

D言語は、適切な組み込みのスコープ終了ガードを提供するため、早期終了に向けて十分に準備されているため、スタイル以外の問題は発生しません。

もちろん、関数はそもそもそれほど長くないはずです。また、巨大なswitchステートメントがある場合、コードもおそらく不適切にファクタリングされます。

勝利のための早期リターン。ugいように見えるかもしれませんがif、特に複数の条件をチェックする必要がある場合は、大きなラッパーほどmuchくありません。

私は両方を使用します。

場合はDoSomething、コードの3-5行で、コードは、単に最初のフォーマット方法を使用して美しく見えます。

しかし、それよりも多くの行がある場合は、2番目の形式を好みます。開始ブラケットと終了ブラケットが同じ画面上にない場合は気に入らない。

single-entry-single-exitの古典的な理由は、そうでなければ正式なセマンティクスが口に出せないいものになることです（GOTOが有害と見なされた同じ理由）。

別の言い方をすれば、戻りが1つしかない場合にソフトウェアがいつルーチンを終了するかを推論するのは簡単です。これは例外に対する議論でもあります。

通常、アーリーリターンアプローチを最小限に抑えます。

個人的には、最初に合格/不合格の条件チェックを行うことを好みます。これにより、関数の最上部で最も一般的な障害のほとんどを、残りのロジックでグループ化できます。

場合によります。

すぐに確認する明らかな行き止まり状態がある場合、関数の残りの部分を無意味に実行することになる早期復帰。*

関数がより複雑で、そうでなければ複数の出口点がある可能性がある場合は、Retval +シングルリターンを設定します（読みやすさの問題）。

* これは多くの場合、設計上の問題を示している可能性があります。残りのコードを実行する前に、多くのメソッドで外部/パラメーターの状態などを確認する必要がある場合は、おそらく呼び出し側で処理する必要があります。

Ifを使用する

GOTOについてのDon Knuthの本では、ifステートメントで最も可能性の高い状態が常に最初に来る理由を説明しました。これはまだ合理的なアイデアであるという仮定の下で（そして時代の速度を純粋に考慮していないものではありません）。コードが失敗しないよりも失敗する可能性が高い場合を除いて、エラー処理に使用されることが多いという事実を考慮すると、早期リターンは良いプログラミング手法ではないと思います:-)

上記のアドバイスに従う場合、その戻り値を関数の下部に配置する必要があります。そして、そこに戻り値を呼び出さずに、エラーコードを設定して2行返すだけですみます。それにより、1エントリ1出口の理想を達成します。

Delphi固有...

Delphiプログラマにとってこれは良いプログラミング手法であると思いますが、証拠はありません。前D2009、我々は値を返すために、原子方法を持っていない、我々は持っているexit;とresult := foo;か、私達はちょうど例外を投げることができました。

代用しなければならなかった場合

if (true) {
 return foo;
} 

ために

if true then 
begin
  result := foo; 
  exit; 
end;

あなたはあなたの機能のすべての1つでそれを好むのにうんざりするかもしれません

if false then 
begin
  result := bar;

   ... 
end
else
   result := foo;

まったく避けexitてください。

次の声明に同意します。

私は個人的にガード句のファンです（2番目の例）。関数のインデントを減らすからです。関数から複数のリターンポイントが発生するため、それらを好まない人もいますが、それらの方が明確だと思います。

stackoverflowのこの質問から取られました。

私は最近、極端に、早期のリターンをほぼ独占的に使用しています。これを書く

self = [super init];

if (self != nil)
{
    // your code here
}

return self;

なので

self = [super init];
if (!self)
    return;

// your code here

return self;

しかし、それは本当に重要ではありません。関数に1つまたは2つ以上のレベルのネストがある場合、それらを無効にする必要があります。

私は書くことを好む：

if(someCondition)
{
    SomeFunction();
}

あなたのように、私は通常最初のものを書きますが、最後のものを好みます。ネストされたチェックがたくさんある場合、通常は2番目の方法にリファクタリングします。

エラー処理がチェックからどのように移動するのが好きではありません。

if not error A
  if not error B
    if not error C
      // do something
    else handle error C
  else handle error B
else handle error A

私はこれが好きです：

if error A
  handle error A; return
if error B
  handle error B; return
if error C
  handle error C; return

// do something

上部の条件は「前提条件」と呼ばれます。を置くとif(!precond) return;、すべての前提条件が視覚的にリストされます。

大きな「if-else」ブロックを使用すると、インデントのオーバーヘッドが増加する可能性があります（3レベルのインデントに関する引用を忘れていました）。

if文を小さくすることを好みます。

したがって、次のいずれかを選択します。

if condition:
   line1
   line2
    ...
   line-n

そして

if not condition: return

line1
line2
 ...
line-n

あなたが「早期返還」として説明したものを選択します。

気を付けてください、私は早期の返品など何も気にしません。コードを単純化したり、ifステートメントの本体を短くしたりしたいのです。

ifとforとwhileがひどい場合は入れ子にしてください。

他の人が言うように、それは依存します。値を返す小さな関数の場合は、早期の戻り値をコーディングできます。しかし、サイズの大きい関数の場合、コードが戻る前に実行されるものを置くことができるとわかっている場所にコードを配置するのが好きです。

私は機能レベルでフェイルファストを練習しています。コードの一貫性とクリーンさを維持します（私と一緒に仕事をした人にとって）。そのため、私はいつも早く帰ります。

いくつかの頻繁にチェックされる条件では、AOPを使用する場合、それらのチェックの側面を実装できます。