voidメソッド内でreturnを使用するのは悪い習慣ですか？

Question 1

次のコードを想像してみてください。

void DoThis()
{
    if (!isValid) return;

    DoThat();
}

void DoThat() {
    Console.WriteLine("DoThat()");
}

voidメソッド内でreturnを使用しても大丈夫ですか？パフォーマンスの低下はありますか？または、次のようなコードを作成することをお勧めします。

void DoThis()
{
    if (isValid)
    {
        DoThat();
    }
}

Question 2

voidメソッドでの戻りは悪くありませんが、ネストを減らすためにステートメントを反転ifするのが一般的な方法です。

また、メソッドのネストが少なくなると、コードの可読性と保守性が向上します。

実際、returnステートメントのないvoidメソッドがある場合、コンパイラーは常にその最後にret命令を生成します。

Question 3

（ネストされたコードではなく）ガードを使用するもう1つの大きな理由があります。別のプログラマーが関数にコードを追加した場合、それらはより安全な環境で動作します。

考えてみましょう：

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }
}

対：

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
}

ここで、別のプログラマーが次の行を追加するとします。obj.DoSomethingElse（）;

void MyFunc(object obj)
{
    if (obj != null)
    {
        obj.DoSomething();
    }

    obj.DoSomethingElse();
}

void MyFunc(object obj)
{
    if (obj == null)
        return;

    obj.DoSomething();
    obj.DoSomethingElse();
}

明らかにこれは単純なケースですが、プログラマーは最初の（ネストされたコード）インスタンスのプログラムにクラッシュを追加しました。2番目の例（ガード付きの早期終了）では、ガードを通過すると、コードはnull参照の意図しない使用から安全になります。

確かに、優れたプログラマーはこのような間違いを犯しません（多くの場合）。しかし、予防は治療よりも優れています。この潜在的なエラーの原因を完全に排除する方法でコードを記述できます。ネスティングは複雑さを増すため、ベストプラクティスでは、ネスティングを減らすためにコードをリファクタリングすることをお勧めします。

Question 4

悪い習慣??? ありえない。実際、検証が失敗した場合は、できるだけ早くメソッドから戻って検証を処理することをお勧めします。それ以外の場合は、ネストされたifとelseが大量に発生します。早期に終了すると、コードの可読性が向上します。

同様の質問に対する回答も確認してください。if-elseの代わりにreturn / continueステートメントを使用する必要がありますか？

Question 5

それは悪い習慣ではありません（すでに述べたすべての理由で）。ただし、メソッドでのリターンが多いほど、より小さな論理メソッドに分割する必要があります。

Question 6

最初の例は、ガードステートメントの使用です。ウィキペディアから：

コンピュータプログラミングでは、ガードはブール式であり、プログラムの実行が問題のブランチで続行される場合はtrueと評価される必要があります。

メソッドの先頭にたくさんのガードを配置することは、完全に理解できるプログラミング方法だと思います。基本的には、「これらのいずれかが当てはまる場合は、このメソッドを実行しないでください」と言っています。

したがって、一般的には次のようになります。

void DoThis()
{
  if (guard1) return;
  if (guard2) return;
  ...
  if (guardN) return;

  DoThat();
}

私はそれがはるかに読みやすいと思います：

void DoThis()
{
  if (guard1 && guard2 && guard3)
  {
    DoThat();
  }
}

Question 7

パフォーマンスの低下はありませんが、2番目のコードは読みやすく、保守が容易です。

Question 8

この場合、2番目の例はより良いコードですが、それはvoid関数から戻ることとは関係ありません。これは、2番目のコードがより直接的であるためです。しかし、void関数から戻ることはまったく問題ありません。

Question 9

これは完全に問題なく、「パフォーマンスの低下」はありませんが、角かっこなしで「if」ステートメントを記述しないでください。

常に

if( foo ){
    return;
}

ずっと読みやすくなっています。また、コードの一部がステートメント内にないのに、そのステートメント内にあると誤って想定することはありません。

Question 10

私はこれについてあなたのすべての若いホイッパースナッパーに反対するつもりです。

メソッドの途中でreturnを使用することは、無効であろうとなかろうと、非常に悪い習慣です。これは、40年近く前に、故Edsger W. Dijkstraによって、よく知られている「有害と見なされるGOTOステートメント」から始まった理由が非常に明確に示されているためです。」、そしてダール、ダイクストラ、ホアによる「構造化プログラミング」を続けています。

基本的なルールは、すべての制御構造とすべてのモジュールに、1つの入口と1つの出口が必要であるということです。モジュールの途中で明示的に戻ると、そのルールが破られ、プログラムの状態について推論するのがはるかに難しくなります。その結果、プログラムが正しいかどうかを判断するのがはるかに難しくなります（これははるかに強力なプロパティです）「それが機能しているように見えるかどうか」よりも）。

「有害と見なされるGOTOステートメント」と「構造化プログラミング」は、1970年代の「構造化プログラミング」革命を開始しました。これらの2つの部分が、if-then-else、while-do、およびその他の明示的な制御構造が今日ある理由であり、高水準言語のGOTOステートメントが絶滅危惧種リストに含まれている理由です。（私の個人的な意見では、彼らは絶滅種リストに載っている必要があります。）

メッセージフロー変調器は、最初の試行で受け入れテストに合格した最初の軍事ソフトウェアであり、逸脱、免除、または「ええ、しかし」の言い回しはなく、言語がない言語で書かれていたことは注目に値します。 GOTOステートメント。

Nicklaus Wirthが、Oberonプログラミング言語の最新バージョンであるOberon-07のRETURNステートメントのセマンティクスを変更し、型付きプロシージャ（つまり、関数）の宣言の最後の部分にしたことにも言及する価値があります。関数本体の実行可能ステートメント。変更の彼の解明は、彼が前のフォームが正確ので、それをやったと言ったWAS構造化プログラミングの一の出口原則の違反。

Question 11

ガードを使用するときは、読者を混乱させないように、特定のガイドラインに必ず従ってください。

関数 は1つのことを行います
警備員は最初のものとしてのみ導入されます、関数のロジックます
ネストされていない部分には、関数のコアインテントが含まれています

例

// guards point you to the core intent
void Remove(RayCastResult rayHit){

  if(rayHit== RayCastResult.Empty)
    return
    ;
  rayHit.Collider.Parent.Remove();
}

// no guards needed: function split into multiple cases
int WonOrLostMoney(int flaw)=>
  flaw==0 ? 100 :
  flaw<10 ? 30 :
  flaw<20 ? 0 :
  -20
;

Question 12

オブジェクトがnullの場合など、何も返さない代わりに例外をスローします。

メソッドはオブジェクトがnullでないことを想定しており、そうではないため、例外をスローして呼び出し元に処理させる必要があります。

しかし、それ以外の場合、早期復帰は悪い習慣ではありません。