通常のパスに従うか、早期に失敗する必要がありますか？

コードコンプリートブック以下の引用が来ます：

「通常の場合は、後ではifなく後に入力しますelse」

つまり、標準パスからの例外/偏差をelseケースに入れる必要があります。

しかし、プラグマティックプログラマーは「早くクラッシュする」ことを教えています（p。120）。

どのルールに従うべきですか？

「早期にクラッシュする」とは、どのコード行がテキスト的に先に来るかではありません。処理のできるだけ早い段階でエラーを検出するように指示するため、すでに障害のある状態に基づいて誤って判断や計算を行うことはありません。

if/ elseどちらも「以前の」または「後」ステップを構成すると言わないことができるように構築ブロックの一方のみが実行されます。したがって、それらをどのように注文するかは読みやすさの問題であり、「早期失敗」は決定に含まれません。

else文に失敗コードのみが含まれている場合、ほとんどの場合、そこにあるべきではありません。

これを行う代わりに：

if file.exists() :
  if validate(file) :
    # do stuff with file...
  else :
    throw foodAtMummy
else :
  throw toysOutOfPram

これを行う

if not file.exists() :
  throw toysOutOfPram

if not validate(file) :
  throw foodAtMummy

# do stuff with file...

エラーチェックを含めるためだけにコードを深くネストしたくありません。

そして、他の誰もがすでに述べているように、2つのアドバイスは矛盾していません。1つは実行順序に関するもので、もう1つはコード順序に関するものです。

両方に従う必要があります。

「早期にクラッシュする」/「早期に失敗する」というアドバイスは、可能な限り早く入力の可能性のあるエラーをテストすることを意味します。
たとえば、メソッドが正（> 0）と想定されるサイズまたはカウントを受け入れる場合、早期失敗アドバイスは、アルゴリズムが意味のないものを生成するのを待つのではなく、メソッドの最初にその条件をテストすることを意味します結果。

通常のケースを最初に置くためのアドバイスは、条件をテストする場合、最も可能性の高いパスが最初に来ることを意味します。これは、通常の場合に関数が何をしているかを理解しようとするときにコードのブロックをスキップする必要がないため、パフォーマンス（プロセッサの分岐予測がより頻繁に行われるため）と可読性に役立ちます。コードの読み取り中にスキップするエラー処理がない
ため、前提条件をテストしてすぐに（アサートまたはif (!precondition) throw構造を使用して）救済する場合、このアドバイスは実際には適用されません。

@JackAidley はその要点をすでに述べていると思いますが、次のように定式化させてください。

例外なし（Cなど）

通常のコードフローには、次のものがあります。

if (condition) {
    statement;
} else if (less_likely_condition) {
    less_likely_statement;
} else {
    least_likely_statement;
}
more_statements;

「早期エラーアウト」の場合、コードは突然読み取ります。

/* demonstration example, do NOT code like this */
if (condition) {
    statement;
} else {
    error_handling;
    return;
}

あなたはこのパターンを見つけた場合- returnにelse（あるいはif問題のコードがないので）ブロック、すぐにそれを手直ししませ持つelseブロックを：

/* only code like this at University, to please structured programming professors */
function foo {
    if (condition) {
        lots_of_statements;
    }
    return;
}

現実世界では…

/* code like this instead */
if (!condition) {
    error_handling;
    return;
}
lots_of_statements;

これは、あまりにも深くネスト回避し、「早期抜け出す」の場合を満たして（心を維持するのに役立ちます-と、コードの流れ-クリーン）と「に可能性が高いものを入れ違反しないifだけで何も存在しないため、一部」elseの部分は、 。

C そしてクリーンアップ

同様の質問（これは間違っていました）の答えに触発され、Cでクリーンアップを行う方法を次に示します。1つまたは2つの出口ポイントを使用できます。2つの出口ポイントに1つあります。

struct foo *
alloc_and_init(size_t arg1, int arg2)
{
    struct foo *res;

    if (!(res = calloc(sizeof(struct foo), 1)))
        return (NULL);

    if (foo_init1(res, arg1))
        goto err;
    res.arg1_inited = true;
    if (foo_init2(&(res->blah), arg2))
        goto err;
    foo_init_complete(res);
    return (res);

 err:
    /* safe because we use calloc and false == 0 */
    if (res.arg1_inited)
        foo_dispose1(res);
    free(res);
    return (NULL);
}

実行するクリーンアップが少ない場合は、それらを1つの終了ポイントにまとめることができます。

char *
NULL_safe_strdup(const char *arg)
{
    char *res = NULL;

    if (arg == NULL)
        goto out;

    /* imagine more lines here */
    res = strdup(arg);

 out:
    return (res);
}

gotoあなたがそれに対処することができれば、この使用はまったく問題ありません。使用を中止するためのアドバイスgotoは、使用が良い、許容できる、悪い、スパゲッティコード、または他の何かであるかどうかをまだ自分で決定できない人々に向けられています。

例外

上記は例外のない言語について語っていますが、私はそれを非常に好みます（明示的なエラー処理をはるかに優れた方法で使用でき、驚きも少​​なくなります）。igliを引用するには：

<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design.
<mirabilos> that too… may I quote you on that?
<igli> sure, tho i doubt anyone will listen ;)

しかし、例外のある言語でそれをうまく行う方法と、それらをうまく使用したい場合の提案があります：

例外が発生した場合のエラー戻り

Earlyのほとんどをreturn例外をスローするように置き換えることができます。しかし、あなたの通常のプログラムの流れは、つまりプログラムが遭遇しなかったで任意のコードの流れ、よく、例外...エラー条件やsomesuch、してはならない任意の例外を発生させます。

この意味は…

# this page is only available to logged-in users
if not isLoggedIn():
    # this is Python 2.5 style; insert your favourite raise/throw here
    raise "eh?"

…大丈夫ですが、…

/* do not code like this! */
try {
    openFile(xyz, "rw");
} catch (LockedException e) {
    return "file is locked";
}
closeFile(xyz);
return "file is not locked";

…ではありません。基本的に、例外は制御フロー要素ではありません。これにより、Operationsが奇妙に見え（「Java™プログラマーは常にこれらの例外は正常であると言う」）、デバッグを妨げる可能性があります（たとえば、例外を発生させるだけでIDEに指示する）。多くの場合、例外を発生させるには、ランタイム環境でスタックをアンワインドしてトレースバックなどを生成する必要があります。これにはおそらく、さらに多くの理由があります。

つまり、例外をサポートする言語では、既存のロジックとスタイルに一致し、自然に感じるものを使用します。ゼロから何かを書く場合は、早めに合意してください。ライブラリをゼロから作成する場合は、消費者について考えてください。（abort()ライブラリでも使用しないでください...）しかし、あなたがすることは何でも、原則として、操作がその後（通常）継続する場合、例外はスローされません。

一般的なアドバイス 例外

まず、開発チーム全体で合意された例外のすべてのプログラム内使用を取得してください。基本的に、それらを計画します。それらを豊富に使用しないでください。場合によっては、C ++、Java™、Pythonでさえ、エラーが返される方が良い場合があります。時々そうではありません。それらを考えて使用してください。

私の意見では、「ガード条件」はコードを読みやすくするための最良かつ最も簡単な方法の1つです。ifメソッドの最初に表示され、elseコードが画面外にあるため表示されない場合、私は本当に嫌いです。見るだけで下にスクロールしなければならないthrow new Exception。

コードを読んでいる人がそれを読むためにメソッド全体を飛び越える必要がなく、代わりに常に上から下にスキャンするように、チェックを最初に置きます。

（@mirabilosの答えは素晴らしいですが、同じ結論に到達するための質問の考え方は次のとおりです。）

私は自分（または他の誰か）が後で関数のコードを読むことを考えています。最初の行を読んだとき、入力について何も仮定できません（とにかくチェックしないものを除く）。だから私の考えは、「わかりました、私は自分の議論で物事をやろうとしていることを知っています。しかし最初に「それらを片付けましょう」-つまり、彼らが私の好みに合わない制御パスを殺します。」 、私は通常の場合を条件付けられたものとは見ていません;私はそれが正常であることを強調したいと思います。

int foo(int* bar, int baz) {

   if (bar == NULL) /* I don't like you, leave me alone */;
   if (baz < 0) /* go away */;

   /* there, now I can do the work I came into this function to do,
      and I can safely forget about those if's above and make all 
      the assumptions I like. */

   /* etc. */
}

この種の条件の順序は、問題のコードセクションの重要度と、使用できるデフォルトがあるかどうかによって異なります。

言い換えると：

A.クリティカルセクションとデフォルトなし=>早期失敗

B.重要ではないセクションとデフォルト=> else部分でデフォルトを使用

C.中間ケース=>必要に応じてケースごとに決定する