== trueを大事にしますか？

私の同僚が絶えず書いています：

if (someBool == true)

それは私を壁に押し上げます！私はそれを大事にするか、単に落とすべきですか？

それは冗長なコードであり、生死ではありません。しかしながら....

頻繁に発生する場合someBoolは、名前の付け方に問題がある可能性があります。良い名前は、==true

if(IsSomeCondition)

または

if(hasCondition)

または

if(somethingExists)

例えば。

私が見るときsomeBool == true、私はプログラマが評価の概念を内部化していないように感じずにはいられません。これはかなり根本的な欠陥です。

しかし、大学で数回夏にプログラミングを教えるために夏を過ごしたため、私の意見は歪められています。彼らがコンセプトを模索すると、冗長性が明らかになりました。

それ以外の有能なプロのプログラマーにとっては、おそらくそうではありません。それはおそらくプログラミングの初期の頃に開発した悪い習慣であり、まったく揺れたことはありません。しかし、インタビューで誰かが最初に見たものだとしたら、それでも少し怖いでしょう。

それも私を夢中にさせますが、彼らに建設的な方法で冗長性を言及し、同意しなくてもそれを落とすと言います。

あるいは、このアプローチを試すこともできます。
あなた：ブール値を評価するために、次のコード規約を使用し始められますか？

if (someBool==true)&&(true==true) {}

Them：なぜそうするのですか？その文の後半は冗長であり、常に真と評価されます。

あなた：ジョージによって、あなたは正しいです。愚かな私。それでは、すべての冗長性のないバージョンを使用してみましょう。どう？

if (someBool) {}

同僚にとって非常に些細なことがあなたの最大の問題であるなら、あなたは自分自身をかなり幸運だと考えるべきだと思います。

あなたは間違いなくこの悪い習慣をやめるべきです。そっと...

二重等号を書くのを忘れがちで、コードは次のようになります。

if (someBool = true)

たとえば、C＃では、これは警告ではなくエラーを生成します。したがって、警告をエラーとして処理しない限り、コードは実行され、変数をtrueに設定し、常に条件を入力します。

私はあなたに同意しますが、ここで悪魔の擁護者を演じるつもりです。

言語と変数の名前に応じて、x == trueが適切です。

静的型付けと整数型の型強制を使用した言語では、次の状況を考慮してください。

if (actionsAllowed){
    //do actions, since they are allowed
    //...
}

コードのこのセクションを読んでいる人はすぐに、actionsAllowedがブール変数であることに気付かない場合があります。許可されたアクションの数を表す整数でもかまいません。したがって、== trueを追加すると、xがブール値であり、ブール値に強制される整数ではないことが明らかになります。

if (actionsAllowed == true){
    //do actions, since they are allowed
    //...
}

nullable boolsはどうですか？

bool? MyFlag = null;

if (MyFlag == true)
    ;  

if (MyFlag)  // error, doesn't compile!
    ; 

通常、コーディング規約が何らかの形でプロジェクトを著しく妨害しているのでない限り、コーディング規約から大したことはしたくないでしょう。私は多くの白熱した議論がコード領域や主要なアンダースコアのような小さなものにエスカレートするのを見ました。

そうは言っ== trueても、条件ステートメントに追加しても問題はありません。実際のところ、== false否定的な条件をテストする際には、感嘆符の先頭ではなく使用する習慣があります。もっと読みやすいと思います。

確立された慣習がある場合、変更する理由がない限り、それに従うと言います。ただし、大きな悪臭を放つ価値はありません。

了解。私はその男です。恥、恥。それが私が学んだ方法であり、頭の中で「自動フォーマット」する方法です。Joelの好みの構文を使用するのは、bool変数に「is」のような動詞接頭辞がある場合だけです。「is」、「can」、「did」などの動詞が必要です。または、動詞「equals」を提供するために==が必要です。私はその習慣を決して破らないかもしれないので、路上で私に「こんにちは」と言わないなら理解します。

「boolean madness code」を思い出させる

if(someBool == true)
   otherBool = false;
else
   otherBool = true

の代わりに：

 otherBool = !someBool

個人的に、私はCベースの言語で「しない」と言う方法を強く嫌います。その小さな感嘆符は見落としがちです。

したがって、私は完全にそれを書きます：

if (someCondition == false) {

しばらくそれを読んだ後、私も対称性が欲しい

if (someCondition == true) {

したがって、の!代わりに使用するCのアーティファクトと考えてくださいnot。

言語に依存しますが、通常は悪い考えです...

Cでは、これを実行しないでください。テストする値がfalse（ゼロ以外）ではなく、「true」として定義された単一の値と等しくない状況を見つけるのは簡単すぎます。

Rubyでこれを行うのは、ブール値true以外のすべてで失敗することを絶対に確信している場合のみです。

C ++およびbool型のその他の静的言語では、冗長であり、の=代わりにタイプミスをするとプログラミングエラーが発生し==たり、コメントに記載されているプロモーションエラーが発生したりする可能性があります。

あなたはそれが悪いと思う？どうですか：

if(someCondition) {
  return true;
} else {
  return false;
}

私は好む

if (bVal)

または

if (!bVal)

でも、それを持ち出すと人々を怒らせるのではないかと心配しているので、私のアドバイスはそれを忘れることです。ごめんなさい！

あなたは彼がそれを間違っていると彼に告げるべきです。

その

if（true == someBool）{

}

もし彼が1つを忘れたら=彼は彼の執筆スタイルに大きな問題を抱えています。

どう？

if (x == "true")

なぜそれは文字列ですか？！

実際、null許容の場合、x == trueのテストが必要になります。:)

私はそのようなコードを書きます！

その理由は次のとおりです。

「if bla == true」は文のように読みますが、「if bla」は多くの場合そうではありません。実際のコードを読むとき、それはただ間違っているように聞こえます。

また、コンパイラーはifブロックでの割り当てについて警告するため、== trueを使用しても実際には危険はありません。（=と混同する）

また、「== true」と書かない人は、「== false」に「！（）」を使用しますか？本当にいです。また、「== false」を使用する場合、「== true」を使用することは非常に一貫性があり、真理を検証する2つの異なる方法があります。

チームの一員として働いていることを忘れないでください。そのため、これらを一緒に解決する必要があります。「他の人とうまくやる」は、小学校を卒業した後でも重要な性格特性です。

通常、「== true」は省略されますが、チームのコーディング標準に含まれていない限り、1分も議論する価値はありません。

私は主にC＃開発者として同意していますが、これが常に当てはまるとは言えません。たとえば、Javascriptでは、===はタイプ合体を実行します。したがって、var x = 3の場合：

if(x) --> true

ながら

if (x === true) --> false

私はJSでもif（x == true）を使用せず、単に何かを考えるため、==とは異なると思います。

私のオフィスで出てきた別のポイントにこの種のタッチ：

bool b = false;

C＃では、bool b; は十分であり、bをfalseに初期化します。ただし、上記の行を記述する方がより明示的であり、とにかく最適化中にコンパイラーによって取り外される必要があります。

だから、私のポイントは、何が良いプラクティスであり、そうでないかが常にそれほど明白ではないということだと思います。

ああはい、しかし変数がnull可能だとしたらどうでしょう？（ブール？）

一部の言語（C＃）では、 'true'との比較とキャストまたは比較が必要になります。

bool? isAccepted = true;

if((bool)isAccepted)
{...}

if(isAccepted == true)
{...}

若者はルールを知っていますが、老人は例外を知っています;）

最新C#では、を扱っているnull-able bool場合、次のことを行う必要があります。

bool? x = null;
bool? y = true;
bool? z = false;
if (x == true || y == true || z == true) {
    // That was the only way that is reasonably readable that I know of
    // to accomplish this expression.
}

トライステートが問題でない場合、通常、何かをtrue/ と比較する理由はないはずTrueです。ただし、Python他のいくつかの言語では、非ブール式でC/C++実行できますif。これらの言語には、整数、ポインター、リストなどを真または偽として解釈するための独自のルールがあります。いつかあなたはそれを望まないでしょう。たとえば、次のPythonスニペットでは：

x = True
y = 'abcdef'
z1 = x and y
z2 = (x == True) and (y == True)

ここにあるz必要がありますがTrue、するz2必要がありますFalse。さて、Clojure言語はさらに別の方法でこれにアプローチします- and関数は必ずしもa boolに評価されるわけではありませんが、それifを処理できます。

言語に関係なく、何かをTrueまたFalseはと比較していることに気づいたときは、おそらくコメントする価値があります。

そのようなコーディングは、以前にも間違った方法で私をこすったでしょう。サンプル識別子の名前は「someBool」ですが、ブール型であることが保証されていない変数にそのコーディングスタイルを誤って使用すると、意図しない動作が発生する可能性があります。「someBool」の値が正確に「true」または「false」でない場合、結果はfalseになります。

昨年、このようなコーディングスタイルが原因で非常に微妙なバグに遭遇しました。これは、そのような構成体に目が光るので識別が困難でした。「どうしてそれが間違っているのだろう」と思うでしょう。「（var）」や「（！var）」などのよく知られた式についても同じことが当てはまり、動作を確認せずにそれらを読んだりコーディングしたりします。

そのため、コードベース内のこのようなバグの存在を減らし、そのような微妙なバグが将来いつか偶然に忍び寄る可能性を減らすために、いくつかのコーディング標準を導入しました。

1. すべての式は、意図ごとに括弧で囲む必要があります。
2. すべてのブールテストは、「suchBool！= false」のように負で表現する必要があります。

新しいスタイルに適合しないコードをクリーンアップすることで、このような微妙なバグのいくつかのインスタンスを特定して修正しました。

次の理由により、ActionScript 2で常にこれを使用する必要がありました（確かに今では死んだ言語です）。

var something:Boolean = org.black.box.unknown.ThisMightNotExistYet();

// this is slightly ambiguous
if(something)
{
}

// because if you allow undefined you might actually mean
if(false != something)
{
}

// which can mean something different than
if(true == something)
{
}

// and comparing against what you actually MEAN is less script than
if(undefined != value && value)
{
}

だから、ほとんどの場合、具体的であることが最善でした。

同意する。特に強力な型付き言語では、冗長な構造です。

ブール値の別の誤用を追加するために、私はJavascriptでこの種の構築を何度も見つけました（特に100以上の行のようないくつかのスパゲッティのようなモンスター機能で）：

//create the variable, not initializing it
var flag;
//...
//assing a value to the var, by the example 
flag=$("mycheckbox").selected;
//...

//and at the moment of use it:
if(flag!=true) {
   //code to execute when the checkbox is unchecked
}

この言語には厳密な型定義がないため、一部のプログラマーはfalse|undefined値をいじる必要がないことを好むようです。

このようなコードを持っている同僚がいます。

if(something == true)

そして、ある種のテスト/デバッグのために、このブロックを呼び出さないようにしたいので、次のように変更します。

if(something == true && false)

そして、時々彼はそれを次のように変更します：

if(false)

最悪の事態は、この種のデバッグがときどきすり減ってしまい、他の開発者が読むのが本当に悪いことです！

コードベースでは一貫性が重要だと思います。そのため、ほとんどの組織で使用されているスタイルを使用する必要があります。好みのスタイルを会社の公式コーディングガイドラインの一部にしてください。既にガイドラインに含まれている場合は、それに従ってください。

（言われていると、それは本当に私を困らせるでしょう-しかし、それから大したことをするのにおそらく十分ではありません）。

余分な== trueを配置しない方がいいのですが、時々誤って含めて気付かないことがあります。その人は気付かないで、誤ってそれらを置いたかもしれません。コードを読み直して、余分な== trueを追加したことに気づいたので、== trueを削除しました。気付かないこともありますが、冗長に配置したと言ってくれる人を喜んで歓迎します。

どうですか：

int j = 1;
for (int i=1; i>=j; i++) ...

はい、見ました。