17

私が尋ねた質問は閉じられているかもしれませんが、すべてのif条件のelse部分を記述する必要があることを知りたいだけです。私の上級プログラマーの1人は、「if条件ごとにelsepartを書く必要がある」と言っていました。else部分に書き込む条件がないとしたら、どうすればよいでしょうか。ここで健全な議論が行われると思います。

4

12 に答える 12

17

それは恐ろしい考えです。最終的に次の形式のコードになります。

if (something) {
    doSomething();
} else {
}

elseまったく持っていないことは私を超えているので、誰もがそれをより読みやすく、維持しやすいと考えることができます。自由な時間が多すぎる人たちが作ったルールのひとつのようですね。できるだけ早く解雇するか、少なくとも静かに静かに離れてください:-)

于 2010-08-03T06:03:33.010 に答える
8

いいえ、少なくともほとんどの言語では、そうする必要はありません。（あなたは指定しませんでした;これを強制する言語がある可能性は十分にあります。）これは私が確かにそうしない例です：

public void DoSomething(string text)
{
    if (text == null)
    {
        throw new ArgumentNullException("text");
    }
    // Do stuff
}

これで、メソッドの主な作業をここで「else」句に入れることができますが、ネストが不必要に増加します。さらにいくつかの条件を追加すると、全体が判読不能な混乱になります。

この「アーリーアウト」のパターンは、私の経験ではかなり一般的であり、例外だけでなく戻り値にも当てはまります。メソッドからの単一のリターンポイントを好む人がいることは知っていますが、私が使用している言語（Java、C＃）では、コードが大幅に読みにくくなり、ネストが深くなることがよくあります。

さて、議論の余地がある状況が1つあります。それは、両方のブランチがターミナルであるという状況ですが、どちらも事実上ショートカットではありません。

public int DoSomething()
{
    // Do some work
    if (conditionBasedOnPreviousWork)
    {
        log.Info("Condition met; returning discount");
        return discount;
    }
    else
    {
        log.Info("Condition not met; returning original price");
        return originalPrice;
    }
}

（私は意図的に両方のブランチに、単に返すよりも多くの作業を与えていることに注意してください。そうでない場合は、条件付きステートメントが適切です。）

これは「else」なしでより読みやすくなりますか？それは本当に個人的な選択の問題であり、私は常に一貫しているとは言いません。両方のブランチを同じようにインデントすると、どういうわけか同じ重みが与えられます。おそらく、条件を逆にすることで後でリファクタリングする可能性があります...一方、「元の価格に戻す」に落としたばかりの場合は、それをifブロックに入れるリファクタリング割引ケースをifブロックから移動すると、一見しただけでは明らかに正しくありません。

于 2010-08-03T06:04:47.783 に答える
5

JavaやCのような命令型言語でif - elseは、はステートメントであり、値を返しません。ですから、その部分だけを楽しく書いてif先に進むことができます。elseそして、毎回空のsを追加するよりも、より良い方法だと思いますif。

ただし、HaskellやClojureなどの関数型言語でifは、は式であり、値を返す必要があります。したがって、成功する必要がありますelse。ただし、セクションが不要な場合もありますelse。そのような場合、Clojureには、セクションに戻ってそれを記述しないようにwhenラップするマクロがあります。if - elsenilelse

(when (met? somecondition)
  (dosomething))
于 2010-08-03T06:23:48.247 に答える
4

危険！危険、迫りくる危険！

http://en.wikipedia.org/wiki/Cargo_cult_programming

空のelse { }ブロックを含めると、コードの品質、可読性、または堅牢性が何らかの形で向上しますか？私はそうは思わない。

于 2010-08-03T06:03:31.413 に答える
1

これを純粋にセマンティックの観点から見ると、すべてのifに暗黙のelseがない単一のケースを考えることはできません。

壁に着く前に車が止まらなければ墜落します。そうでなければ墜落しません。

セマンティクスはさておき：

その質問への答えは、環境と、間違いの結果が何であるかによって異なります。

ビジネスコード？あなたのコーディング標準が言うことをしてください。
私見では、最初は手間がかかりすぎるように見えますが、そのコードを再検討すると、10年後には非常に貴重なものになることがわかります。しかし、あなたが重要な「反条件」を逃したならば、それは確かに世界の終わりではないでしょう。

ただし、セキュリティ、セーフティ、またはライフクリティカルコード？それは別の話です。

この場合、2つのことを実行します。まず、障害をテストするのではなく
、障害がない ことを証明する必要があります。これには、モジュールへのエントリに関する悲観的な見方が必要です。あなたはそれが正しいことを証明するまですべてが間違っていると思います。 第二に：人生において重要：あなたは決して患者を傷つけたくない。：

bool everyThingIsSafe = true;
if(darnThereIsAProblem())
{
   reportToUserEndOfWorld();
}
return everyThingIsSafe;

おっと。everyThingIsSafeをfalseに設定するのを忘れました。
このスニピットを呼び出したルーチンは、現在、嘘をついています。evertThingIsSafeをfalseに初期化した場合-私は常に安全ですが、エラーがなかったことを示すためにelse句が必要になります。
はい、これをポジティブテストに変更することもできましたが、障害を処理するために他のテストが必要です。
そして、はい、everyThingIsSafe（）にチェックの即時リターンを割り当てることができました。次に、フラグをテストして問題を報告しました。暗黙のelse、なぜ明示的ではないのですか？
厳密に言えば、これが表す暗黙のelseは合理的です。
FDA /安全監査人にとっては、そうではないかもしれません。
それが明示的である場合、テスト、それ以外、および私が両方の条件を明確に処理したことを示すことができます。

私は25年間医療機器のコーディングを行ってきました。この場合、elseが必要であり、caseのデフォルトが必要であり、それらが空になることはありません。何が起こるのか、またはできるだけ近くで何が起こるのかを正確に知りたいと考えています。状態を見落とすと誰かを殺す可能性があるからです。

Therac-25を調べてください。8人が重傷を負った。3人が死亡。

于 2014-01-24T17:40:31.067 に答える
1

私は遅れていることを知っていますが、私はこれについて多くのことを考え、私の結果を共有したいと思いました。

重要なコードでは、すべてのブランチが考慮されることが不可欠です。elseを書く必要はありませんが、elseが不要であるというマークとその理由を残してください。これはレビュー担当者に役立ちます。観察：

//negatives should be fixed
if(a < 0) {
    a+=m;
}
//else value is positive
于 2015-02-10T08:59:23.947 に答える
1

いいえ、ステートメントのelse部分を記述する必要はありませんif。

else実際、ほとんどの開発者はブロックを回避することを好み、推奨しています。

あれは

書く代わりに

if (number >= 18) {
    let allow_user = true;
} else {
    let allow_user = false;
}

ほとんどの開発者は次のことを好みます。

let allow_user = false;
if (number >= 18) {
    let allow_user = true;
}
于 2019-08-22T11:08:16.797 に答える
0

いいえ、する必要はありません..

また、 elseブロックが空になることが多いので、読みやすくするのは良い考えではないと思います。見た目はきれいではありません。

于 2010-08-03T06:00:27.937 に答える
0

いいえ、しかし私は個人的には避けるために常に中括弧をカプセル化することを選択します

if (someCondition)
    bar();
    notbar();  //won't be run conditionally, though it looks like it might

foo();

私は書くだろう

 if (someCondition){
        bar();
        notbar();  //will be run
 }
 foo();
于 2010-08-03T06:04:19.657 に答える
0

他に部分がない場合もあります。空の部分を含めると、コードが読みにくくなります。

于 2010-08-03T06:04:57.213 に答える
0

これは純粋にスタイルと明快さの問題です。ステートメント、特に他のステートメントが非常に不要な単純なステートメントであるかどうかは容易に想像できます。しかし、より複雑な条件があり、おそらく多くのさまざまなケースを処理している場合、それ以外の場合は何もすべきではないことを明示的に宣言することが明確になることがよくあります。// do nothingこのような場合は、スペースが意図的に空白になっていることを明確にするために、それ以外の場合は空のコメントを残しておきます。

于 2010-08-03T06:05:37.703 に答える
0 
def in_num(num):
    if num % 3 == 0:
        print("fizz")
    if num % 5 == 0:
        print("buzz")
    if (num % 3 !=0) and (num % 5 !=0):
        print(num)

このコードを参照してください。elseステートメントは必要ありません。

于 2022-01-07T07:26:45.520 に答える