web-dev-qa-db-ja.com

「false or」または「true and」を条件に追加することは悪い習慣ですか？

コードの汎用性や使いやすさを促進するためにfalse or ...またはtrue and ...を追加することは悪い習慣ですか？

のように：

SELECT *
FROM table
WHERE TRUE
AND IsEnabled
AND SomeField = some_value
AND SomeOtherField != some_value

sQLまたはJavaScriptの例：

if (false
      || prop === 'category'
      || prop === 'subCategory'
      || prop === 'productLogisticGroup'
      || prop === 'productName'
      || prop === 'color'
      || prop === 'configuration'
)

これにより、条件がエッジ上にあるかどうかに関係なく、思考プロセスを削除することで、条件の追加または削除が少し簡単になります。これはどういうわけか悪いですか？

programming-practiceslanguage-agnosticpatterns-and-practicesconditions
8
Nae

いくつかの便利なコーナーケースがありますが、あなたの例は私にとって特に意味がありません。一時的にブロックを切り替えたい場合や、ブロックに強制的に入れたい場合は、主にデバッグに使用します。また、breakメソッドがそれほど単純ではない、またはbreak条件が外部のブール値ではなく内部の計算に依存するスレッドメソッドのような連続ループにも使用します。しかし、真または偽は実際には重要です。あなたの例では、それらは純粋に審美的であり、誰かがあなたのコードを読んだ場合、眉毛を上げる可能性があります。

しかし、これがあなたの転がり方なら、あなたにもっと力を与えます。

6
Martin Maat

コンパイラは通常それを削除するので、害はありません。私はそれが何か有用なものを追加するとは思わない。

ただし、これを目にしたほとんどの場合は、誰かが実行時にSQLクエリ文字列を作成しているときであり、これは通常は悪い習慣です。バグ（またはSQLインジェクションの脆弱性）を導入するのは簡単で、テストまたはデバッグは困難です。

FWIW、ここに私があなたの例を書く方法があります：

SELECT *
FROM table
WHERE IsEnabled
  AND SomeField = some_value
  AND SomeOtherField != some_value


switch (prop)
{
     case 'category';
     case 'subCategory';
     case 'productLogisticGroup';
     case 'productName';
     case 'color';
     case 'configuration';
         DoTheThing();
         Break;
}
1
Robin Bennett

私は書く傾向があります

if (   prop === 'category'
    || prop === 'subCategory'
    || prop === 'productLogisticGroup'
    || prop === 'productName'
    || prop === 'color'
    || prop === 'configuration')

xcodeが適切に処理し、すべての行を簡単に削除できるためです。最初と最後の行は少しトリッキーです。

0
gnasher729