ELSEの悪いプログラミングを使用していますか？[閉まっている]

ELSEコンストラクトを使用することによって引き起こされるバグに頻繁に出くわします。主な例は、次のようなものです。

If (passwordCheck() == false){
    displayMessage();
}else{
    letThemIn();
}

私にとってこれはセキュリティの問題を叫ぶ。passwordCheckがブール値である可能性が高いことは知っていますが、アプリケーションのセキュリティを設定しません。その文字列、intなどの場合はどうなりますか？

私は通常ELSE、の使用を避けようとし、代わりに2つの完全に独立したIFステートメントを選択して、期待するものをテストします。それ以外はすべて無視されるか、具体的に処理されます。

確かに、これはアプリに入るバグ/セキュリティ問題を防ぐためのより良い方法です。

どうやってやるの？

elseブロックは常に、あなたがデフォルトの動作になりたい何で構成する必要があります。

それらを避ける必要はありません。適切に使用するよう注意してください。

あなたの例では、デフォルトの状態はアクセスを許可しないことです。少しリファクタリングすると、次のことができます。

If (passwordCheck)
{
   letThemIn();
}
else
{
   displayMessage();
}

すなわち、パスワードチェックが機能する場合、それらを入れてください。そうでなければ、何らかのエラーメッセージを表示することは常に有効です。

もちろんelse if、完全に別個のifステートメントではなく、使用することにより、ロジックにチェックを追加できます。

いいえ、問題はありませんELSE。ELSEは新しいものではありませんGOTO。実際、IF代わりに2を使用ELSEすると、いくつかの問題が発生する可能性があります。

例1：

if (this(is(a(very())==complex(check())))) {
   doSomething();
}

if (!this(is(a(very())==complex(check())))) {
   doTheOtherThing();
}

コピーペーストが表示されますか？片方を変更してもう片方を忘れる日を待つだけです。

例2：

foreach(x in y) {
  if (first_time) {
    first_time = false;
    doSomething();
  }

  if (!first_time) {
    doTheOtherThing();
  }
}

ご覧のとおりIF、条件がすでに変更されているため、最初のアイテムに対して2番目のアイテムも実行されます。実際のプログラムでは、このようなバグを見つけるのは困難です。

ELSEが常にあります。書くなら

if(foo)
  bar();

あなたは実際に書く

if(foo)
{
  bar();
}
else
{
   // do nothing
}

ELSE-pathに入れるものは何でもあなたの責任です。

個人的にはelseできる限り避ける傾向がありますが、セキュリティ上の問題のためではありません。

コードを読み取るとき、ネストされたステートメントは、どの条件のセットがそこにつながるかを覚えておく必要があるため、ロジックに従うことが難しくなります。このため、私は早期終了の大ファンです。

if (checkPassword != OK) { displayMessage(); return; }

letThemIn();

これもに適用forし、while私が使用するするループcontinueとbreak、それは、インデントのレベルを回避するたびに。

Chris Lattnerは、LLVM Coding Standardsで行うよりも優れていると言います。

次に、それらを交換します。

If (passwordCheck == true)
{
     letThemIn();
}
else
{
     displayMessage();
}

Matthieu M.のように、深くネストされたelseブロックよりも早期に終了することを好みます。多くの人々が私たちに反対し、独自の出口を好むでしょう。それは議論のポイントではない（私は思う）。

今、私はelseそれが理にかなっているとき、特に単純で短い代替品のために確かに使用します。前述のように、テストの複製は時間の浪費であり（プログラマーとCPU）、混乱の原因であり、後にバグ（一方が変更され、他方が変更されない場合）の原因となります。
いつか、そのelse部分にコメントを追加して、条件が何であったか（特にif、たとえばレガシーコードのように部分が長い場合）または代替手段を思い出させます。

関数型プログラミングの極端な支持者の中にはif、パターンマッチングを優先して、完全に削除することを提案しているものがあることに注意してください。:-)

ELSEの使用に問題はありません。ただし、コードの読み取りと理解が非常に複雑になる可能性があります。悪いデザインを示している可能性があります。確かに、テストする必要がある追加のユースケースを示しています。

可能であればELSEを削除してみてください-しかし、それについては妄想しないでください。Steve McConnellは、この完全なコードをCode Completeで呼び出します。つまり、コードには単純で明確なパスがあります。

特定の問題を解決する方法：

• ポリモーフィズムを使用します。システムの境界で、ユーザーのセキュリティ資格情報を検証します。それらが正当なものであれば、システムの関連部分へのアクセス権を持つセッションオブジェクトを返すか、例外をスローします。ただし、これによりシステムがより複雑になる可能性があります。したがって、理解しやすく保守しやすいものを決定します。

一般的に、次はコード内のELSEを削減するのに役立ちます。

• 適切な要件があると、コードでのそのような決定の必要性が減る場合があります。ユースケース（その他）を実装する必要はまったくありません。
• より明確な設計。最大の凝集力と最小限の結合。これにより、コンポーネントが他のコンポーネントで行われた決定を複製しないようにします。
• エラーケースを管理するための例外処理。
• ポリモーフィズム（上記の例を参照）。
• switchステートメント-これらはELSEの美化されたものですが、特定の状況ではより優れています。

コードがセキュリティリークであるという仮定は、使用している言語によって異なる場合があります。Cコードでは問題になる可能性があります（特にCではブール値がゼロまたはゼロ以外のintであるため）。しかし、最も強く型付けされた言語（つまり、実行時型チェック）では、passwordCheck変数がブール値として宣言された場合、他に何かを割り当てる方法はありません。実際、ifブール演算子を使用するか、単に値を使用するかにかかわらず、述語のすべてがブールに解決される必要があります。passwordCheckランタイムにバインドされた別のタイプのオブジェクトがある場合、何らかのタイプの不正なキャスト例外がスローされます。

単純なif / elseコンストラクトはif / ifコンストラクトよりも読みやすく、誰かがコンストラクトを反転させようとした場合に不注意な問題が発生しにくくなります。同じ例を少し見てみましょう。

if(passwordCheck == false) {
    denyAccess();
}

if(passwordCheck) {
    letThemIn();
}

上記で実行する相互排他句の意味は失われます。それがif / elseコンストラクトが伝えるものです。相互に排他的な2つの実行ブランチ。1つは常に実行されます。これはセキュリティの重要な部分letThemInです。-を呼び出した後は、方法がありませんdenyAccess。

コードを明確にするため、および重要なセクションが最も保護されていることを確認するために、それらはプライマリ句（ifパート）内にある必要があります。デフォルトの非準拠の動作は、代替句（elseパート）にある必要があります。例えば：

if(passwordCheck) {
    letThemIn();
} else {
    denyAccess();
}

注：さまざまな言語で作業する際に、「文字列ならどうなるのか？」という質問を避けるのに役立つコーディング習慣を開発しました。基本的に、定数をブール式に最初に入れることです。たとえば、チェックする代わりに、passwordCheck == false私はチェックしていfalse == passwordCheckます。これにより、C ++で起こりうる偶発的な割り当ての問題も回避できます。このアプローチを使用すると、コンパイラはの=代わりに入力すると文句を言い==ます。JavaやC＃などの言語では、コンパイラはif句の割り当てをエラーとして扱いますが、C ++は喜んで受け入れます。だから、私もnull最初にnullチェックを行う傾向があります。

言語を定期的に変更する場合は、定数を最初に配置すると非常に役立ちます。ただし、私のチームではコーディング標準とは反対であり、コンパイラはとにかくこれらの問題をキャッチします。破るのは難しい習慣になります。

elseプログラミング時に使うのが悪いとotherwise言うのは、話すときに使うのは悪いと言うようなものです。

確かに、それらは両方とも悪い方法で使用することができますが、それはあなたがそれらを含むために起こった間違いを犯したという理由だけでそれらが回避されるべきであることを意味しません。多くのバグdefaultがswitchステートメント内の欠落したケースに依存していても、私は驚かないでしょう。

Elseアプリケーションフローをホワイトリストに登録すると考えてください。アプリケーションフローの続行を許可する必要がある条件を確認し、これらの条件が満たされない場合はElse、問題を解決するか、アプリケーションの実行を中止するか、または同様のものを実行します。

Else それ自体は悪くはありませんが、それをうまく使用しないと、望ましくない効果を見ることができます。

また、についてのあなたの声明に関して

「passwordCheckがブール値である可能性が高いことは知っていますが、アプリケーションのセキュリティをそれにしません。」

開発するメソッドの場合、常に1つのデータ型が返されます。PHP Coreには2つ以上のデータ型を返すコードが散らばっていますが、これは関数呼び出しの推測を行うため、悪い習慣です。複数のデータ型を返す必要がある場合は、例外をスローすることを検討してください（これが別のデータ型を返す理由であることがよくあります-何かが恐ろしく、恐ろしく間違っていました）、またはコードを再構築して1つのデータ型のみを返します。

まず第一に。笑！他を避ける理由はまったくありません。形や形を問わず、決して悪い習慣ではありません。

何かあれば、コードは

if(!IsLoggedIn) { ShowBadLoginOrNoAccessPage(); return }

そこに2つのifsはなく、他にありません。これは、例外をスローするものを除くすべてのアプリで行うことです。例外は、表示する適切なページのURLをチェックする関数でキャッチされます（または、asp.netエラー関数にキャッチ/チェックを入れることができます）。許可しない、または例外で使用するすべてのメッセージを示す汎用ページを出力します（例外のタイプを常にチェックし、httpステータスコードを設定します）。

-編集-ammoQの例にあるように、2つのifsはばかげています。本当に elseはifと同じかそれ以上です。ifsを回避する必要がある場合（個人的にはいけませんが、リターンを使用し、頻繁にブレークします）、より多くのコードパスがバグの可能性を高めると言われています。循環的複雑度を参照

-Edit 2- if / elseの使用法が心配な場合。また、次のように一番短いコードブロックを一番上に置くことが私の好みであることにも注意してください。

if(cond == false) {
    a()
    b()
    c()
    onetwothree()
}
else
{
    a()
    b()
    c()
    more()
    onetwothree()
    code()
    longer()
}

むしろその後

if(cond) 
{
    a()
    b()
    c()
    more()
    onetwothree()
    code()
    longer()
}
else
{
    a()
    b()
    c()
    onetwothree()
}

可能な場合、条件の前にデフォルトを設定するのが好きです。私はそれが少し読みやすく、もう少しはっきりしているように感じますが、これは単なる好みです。私は自分のコードでマイナス条件を回避しようとする傾向があります。私は！fooまたはfalse == fooをチェックすることを大したファンではありません。

foo = bar;

if ('fubar' == baz) {
    foo = baz;
}

の代わりに ...

if ('fubar' == baz) {
    foo = baz;
} else {
    foo = bar;
}

前のコードブロックは、私にとって読みやすいように思えます。私のコードについて一種の懐疑的な妄想を持つことは、私にとってより自然に思えます。条件に関係なくデフォルトを設定すると、快適に感じることができます：P

私は、あらゆる種類の分岐ロジックの使用を可能な限り避けるべきだと主張します。ELSEやIFには何も問題はありませんが、分岐ロジックを使用する必要性を最小限に抑えるためのコードを記述する方法はたくさんあります。分岐ロジックは完全に排除できるとは言っていません-一部の場所で必要になりますが、コードのリファクタリングを行ってそのかなりの部分を排除することは可能です。ほとんどの場合、これによりコードの明瞭度と精度が向上します。

一例として、三項演算子も通常は適切な候補です。

If VIP Then 
  Discount = .25
Else
  Discount = 0
End If
Total = (1 - Discount) * Total

三項アプローチの使用：

Discount = VIP ? .25 : 0
Total = (1 - Discount) * Total

三項演算子は、分岐を適切な方法で右にシフトします。