c++ - 等しいかどうかを確認する方法は？（0 == i）または（i == 0）

Question

さて、次の2行が同等であることがわかります-

(0 == i)
(i == 0)

また、以前は最初の方法が推奨されていました。これは、誤って「==」ではなく「=」を使用した場合にコンパイラがエラーメッセージを表示する可能性があるためです。

私の質問は、今日の世代の非常に洗練されたIDEとインテリジェントなコンパイラでは、まだ最初の方法をお勧めしますか？

特に、次のコードを見たときに、この質問が頭に浮かびました-

if(DialogResult.OK == MessageBox.Show("Message")) ...

私の意見では、私は上記を決してお勧めしません。セカンドオピニオンはありますか？

score 74 · Accepted Answer

私は2番目のもの（i == 0）を好みます。なぜなら、それを読むときははるかに自然に感じるからです。あなたは人々に「あなたは21歳以上ですか？」と尋ねますが、「21はあなたの年齢以下ですか？」ではありません。

score 21 · Accepted Answer

C＃では、変数を最初に配置するか最後に配置するかは重要ではありません。割り当てはbool（またはboolにキャスト可能なもの）に評価されないため、コンパイラは「if（i = 0）EntireCompanyData.Delete（）」

したがって、少なくともC＃の世界では、必死ではなくスタイルの問題です。そして、変数を最後に置くことは、英語を話す人にとって不自然です。したがって、より読みやすいコードの場合は、最初に変数を使用します。

score 12 · Accepted Answer

スイッチでうまく表現できないifのリストがある場合（おそらく言語の制限のため）、私はむしろ見たいと思います：

if (InterstingValue1 == foo) { } else
if (InterstingValue2 == foo) { } else
if (InterstingValue3 == foo) { }

確認する必要のある重要な値をすばやく確認できるためです。

特に、Javaでは次のことを行うと便利です。

if ("SomeValue".equals(someString)) {
}

someStringがnullである可能性があるため、この方法ではNullPointerExceptionが発生することはありません。nullになる可能性のあるオブジェクトに対して、nullになることはないとわかっている定数を比較する場合も、同じことが当てはまります。

score 9 · Accepted Answer

(0 == 私)

私はいつもこれを選びます。今日のほとんどのコンパイラが条件文での変数の代入を許可していないのは事実ですが、一部のコンパイラは許可しています。今日の Web プログラミングでは、システム上で無数の言語を使用する必要があります。0 == i を使用することで、条件ステートメントが正しいことが常にわかり、間違いを見つけるためにコンパイラ/インタプリタに頼ることはありません。これで、C# から C++ または JavaScript にジャンプする必要がある場合、コード内の条件ステートメントで代入エラーを追跡する必要がないことがわかりました。これほど小さなもので、その時間を節約するのは簡単なことです。

score 8 · Accepted Answer

以前は、読みやすいオプション (i == 0) の方が適していると確信していました。

その後、($var = SOME_CONSTANT) 型のバグである (ありがたいことに私のものではありません) 生産上のバグがすり抜けました。クライアントは、他のクライアント向けの電子メールを受け取り始めました。機密タイプのデータも同様です。

Q/A がそれをキャッチするべきだったと主張することができますが、彼らはそうではありませんでした。それは別の話です。

その日以来、私は常に (0 == i) バージョンを推し進めてきました。それは基本的に問題を取り除きます。不自然に感じるので、間違えないように気をつけます。ここでそれを間違える方法はありません。

また、誰かが誤って if に値を代入した場合よりも、誰かがコードレビューで if ステートメントを逆にしなかったことに気付く方がはるかに簡単です。フォーマットがコーディング標準の一部である場合、人々はそれを探します。通常、コードレビュー中にコードをデバッグすることはなく、目は a (i == 0) と an (i == 0) をスキャンするようです。

私はまた、Java "Constant String".equals(dynamicString) の大ファンでもあります。null ポインター例外がないことは良いことです。

score 7 · Accepted Answer

ご存知のとおり、私は常に条件付きのif（i == 0）形式を使用します。これを行う理由は、ほとんどのコードをC＃で記述し（とにかく他のコードにフラグを立てる）、テストファーストを実行するためです。私の開発と私のテストへのアプローチは、一般的にこの間違いをとにかくキャッチします。

私は彼らが0==i形式を強制しようとした店で働いていましたが、書くのが面倒で、覚えるのが面倒で、簡単に手に負えない果物を探していたコードレビューアにとっては飼料になってしまいました。

score 6 · Accepted Answer

実際、DialogResultの例は、私がそのスタイルをお勧めする場所です。if（）の重要な部分を左に配置します。それが右側にあり、MessageBoxにさらに多くのパラメーターがある場合（おそらく）、それを表示するには右にスクロールする必要があるかもしれません。

OTOH、私は「（0 == i）」スタイルで多くの使用を見たことがありません。定数を最初に置くことを覚えている場合は、2つの等号を使用することを忘れないでください。

score 6 · Accepted Answer

私は常に最初のケース (0==i) を使用しようとしていますが、これで何度か命が救われました!

score 3 · Accepted Answer

ただのスタイルの問題だと思います。また、代入演算子を誤って使用する場合にも役立ちます。

私は絶対にプログラマーに成長するように頼むつもりはありません。

score 3 · Accepted Answer

私は（i == 0）を好みますが、それでも自分で行う「ルール」（0 == i）を作成し、毎回それを破ります。

「え？」と思います。

さて、左に左辺値を置くという意識的な決定をしている場合は、「==」に「=」と入力すると、入力内容に十分注意を払っています。私は願います。C / C ++では、私は通常、自分のコードに-Wallを使用します。これにより、とにかくほとんどの "=" for"=="エラーに対してgccで警告が生成されます。最近その警告を見たのを覚えていません。おそらく、プログラムを長くするほど、以前に犯したエラーについて反射的にパラノイアになっているからです...

if(DialogResult.OK == MessageBox.Show("Message"))

私には見当違いのようです。トリックのポイントは、誤って何かに割り当てないようにすることです。

しかし、DialogResult.OKがMessageBox.Show（ "Message"）よりも割り当て可能なタイプに評価される可能性が高いか低いかは誰が言うのでしょうか。Javaでは、メソッド呼び出しを割り当てることはできない可能性がありますが、フィールドは最終的なものではない可能性があります。したがって、= for ==と入力することを心配している場合は、この例のJavaでは実際には逆になっているはずです。C ++では、どちらも、または両方を割り当てることはできません。

（0 == i）は、数値リテラルが割り当て可能ではないことを絶対的に確実に知っているためにのみ役立ちますが、iは割り当て可能である可能性があります。

比較の両側が割り当て可能である場合、この方法で偶発的な割り当てから身を守ることはできません。これは、調べずにどちらが割り当て可能かわからない場合に当てはまります。「直感に反する方法でそれらを配置すれば、安全になる」という魔法のトリックはありません。私の「常にルールを破る」ルールと同じように、この問題に注目が集まっていると思います。

score 3 · Accepted Answer

読みやすくなるという単純な理由から、（i == 0）を使用します。それは私の頭の中で非常にスムーズな流れを作ります。デバッグやその他の目的でコードを読み返すと、本を読むように流れるだけで、より意味があります。

score 2 · Accepted Answer

私の会社は、コーディング標準からif（0 == i）を実行するという要件を削除しました。私はそれがどのように多くの意味をなすかを見ることができますが、実際にはそれは逆に見えます。デフォルトでCコンパイラがif（i = 0）について警告を出さないのは少し残念です。

score 2 · Accepted Answer

3番目のオプション-条件内での割り当てを完全に禁止します：

信頼性の高い状況では、条件ステートメントで変数を割り当てることは許可されていません（前のコメントで適切な説明がない場合）-コンパイラーまたはLINTでオフにし、非常に制御された状況でのみオフにするため、この質問は完全に排除されます使用してもよろしいですか？

割り当てが条件付きで発生するか外部で発生するかにかかわらず、通常は同じコードが生成されることに注意してください。これは、コードの行数を減らすための単なるショートカットです。ルールには常に例外がありますが、条件付きである必要はありません。必要に応じていつでも、ルールから抜け出すことができます。

したがって、別のオプションは、そのようなステートメントを禁止することです。必要に応じて、コメントを使用して、この一般的なエラーのLINTチェックをオフにします。

-アダム

score 1 · Accepted Answer

平易な（そして曖昧な）英語で行を表現しようとすると、（i == 0）はより自然に聞こえると思います。それは実際にはプログラマーのコーディングスタイルや彼らが順守する必要のある標準に依存します。

score 1 · Accepted Answer

個人的には（1）が好きではなく、常に（2）を実行しますが、ダイアログボックスやその他の非常に長い方法を扱う場合は、読みやすくするために逆になります。見た目は悪くありませんが、MessageBoxを完全な長さに拡張すると。どのような結果が返されるかを理解するには、右端までスクロールする必要があります。

したがって、値型の単純な比較についてのあなたの主張には同意しますが、必ずしもそれがメッセージボックスのようなもののルールであるべきだとは思いません。

score 1 · Accepted Answer

どちらも同じですが、0==iバリアントを少し好みます。

文字列を比較する場合、「MyString」を比較するとエラーが発生しやすくなります。equals（getDynamicString（））

なぜなら、getDynamicString（）はnullを返す可能性があるからです。より一貫性を保つために、0==iと記述します

score 1 · Accepted Answer

まあ、それは問題の言語とコンパイラに依存します。コンテキストがすべてです。

JavaとC＃では、2つのブール値を比較している非常にまれな状況を除けば、「比較ではなく割り当て」のタイプミスは無効なコードになります。

C / C ++で「安全な」形式を使用する理由は理解できますが、率直に言って、ほとんどのC / C ++コンパイラは、タイプミスをすると警告を表示します。そうでないコンパイラを使用している場合は、理由を自問する必要があります:)

2番目の形式（変数、次に定数）は、私の見解ではより読みやすくなっています。問題が発生しないように、どこでも使用します。

score 1 · Accepted Answer

C では、はい。ただし、既にすべての警告を有効にし、警告なしでコンパイルしている必要があります。多くの C コンパイラは、この問題を回避するのに役立ちます。

読みやすさの POV から得られるメリットはほとんどありません。

score 1 · Accepted Answer

すべてのコーディング標準のルール 0 は、「他の人間が簡単に読めるコードを書く」ことです。そのため、私は (最も急速に変化する値) に対して (あまり急速に変化しない値、または定数) テストを行います。つまり、この場合は "i == 0" です。

この手法が有用な場合でも、ルールは「常に定数を左に置く」ではなく、「左辺値を比較の左に置くことを避ける」べきです。これは通常の解釈方法です。たとえば、何もありません書くことで得られる

if (DateClass.SATURDAY == dateObject.getDayOfWeek())

getDayOfWeek() が定数を返す場合 (したがって、左辺値ではない) とにかく!

私は (この点で少なくとも) 幸いなことに、最近は主に Java でコーディングしており、前述のように if (someInt = 0) はコンパイルされません。

ほとんどの場合、2 つのブール変数を比較するか (この場合、それらを交換しても役に立ちません)、フラグが設定されているかどうかをテストしているため、2 つのブール値を比較する際の注意点は少し面倒です。 -betide-あなたの条件で何かを明示的にtrueまたはfalseと比較しているのを見つけたら! グル！

score 1 · Accepted Answer

コードの読みやすさは、数百行を超えるコードにとって最も重要なことの 1 つであり、間違いなく i == 0 はその逆よりもはるかに読みやすくなります。

score 0 · Accepted Answer

多分あなたの質問への答えではありません。同等性の代わりに===（同一性をチェック）を使用しようとしています。このように型変換は行われず、プログラマーは正しい型が渡されることを確認する必要があります。

score 0 · Accepted Answer

読者は主に左側の列を閲覧する傾向があるため、重要なコンポーネントを最初に配置すると読みやすくなります。重要な情報をそこに配置すると、確実に気付くことができます。

ただし、同僚に話しかけることは絶対にしないでください。冗談でもそれがあなたの行動になることを示唆しても、ここで高い評価を得ることはできません。

score 0 · Accepted Answer

私はいつも2番目の方法を使います。C＃では、

if (i = 0) {
}

とにかくコンパイラエラー（intをboolに変換できない）が発生するため、間違いを犯す可能性は実際には問題ではありません。boolをテストする場合、コンパイラはまだ警告を発行しているので、boolをtrueまたはfalseと比較しないでください。今、あなたは理由を知っています。

score 0 · Accepted Answer

これは私の最大のペットのおしっこの1つです。過去20年間に作成されたCコンパイラが自動的にキャッチできるものをキャッチするために、コードの可読性を低下させる理由はありません（（0 == i）の場合、0の値はどのように変更できますか？）。

はい、私は知っています、ほとんどのCおよびC++コンパイラはデフォルトでこれをオンにしません。適切なスイッチを調べてオンにします。あなたのツールを知らないことの言い訳はありません。

とにかく通常はフラグを立てる他の言語（C＃、Python）に忍び寄るのを見ると、本当に神経質になります！

score 0 · Accepted Answer

どちらか一方を強制する唯一の要因は、ツールチェーンが式の代入をキャッチするための警告を提供しない場合だと思います。開発者としての私の好みは関係ありません。式は、ビジネスロジックを明確に提示することでより適切に提供されます。(0 == i) が (i == 0) よりも適している場合は、それを選択します。そうでない場合は、他のものを選択します。

式の多くの定数は記号名で表されます。一部のスタイルガイドでは、識別子に使用できる品詞も制限されています。これらをガイドとして使用して、式の読み方を形成します。結果の式が疑似コードのように大まかに読める場合、通常は満足です。私はただ表現に任せるだけで、もし私が間違っていれば、たいていは査読に巻き込まれるでしょう。

score 0 · Accepted Answer

私は個人的に可変オペランド値形式の使用を好みます。これは、「自然」に感じるほど長く使用しているという理由と、それが優勢な慣例のように思われるためです。次のような代入ステートメントを利用する言語がいくつかあります。

:1 -> x

したがって、これらの言語のコンテキストでは、たとえそれが有効であっても、次のように表示すると非常に混乱する可能性があります。

:if(1=x)

ですから、それも考慮すべきことです。メッセージボックスの応答が、読みやすさの観点から値オペランド変数形式を使用する方がうまく機能するシナリオの 1 つであることに同意しますが、一貫性を求める場合は、その使用を控える必要があります。

score -1 · Accepted Answer

私たちの IDE がどれだけ優れているかについては、延々と語り継がれるかもしれませんが、IDE の警告レベルを下げている人の数には、いまだにショックを受けています。

したがって、私にとっては、どのプログラマーが何をしているのかわからないので、常に人々に (0 == i) を使用するように依頼することをお勧めします。「後悔するよりも安全」である方がよい

score -3 · Accepted Answer

if(DialogResult.OK == MessageBox.Show("Message")) ...

このように比較を書くことを常にお勧めします。MessageBox.Show("Message") の結果が null になる可能性がある場合、比較が逆の場合は NPE/NRE のリスクがあります。

NULL を含む世界では、数学演算と論理演算は再帰的ではありません。

c++ - 等しいかどうかを確認する方法は？（0 == i）または（i == 0）

28 に答える 28

3番目のオプション-条件内での割り当てを完全に禁止します：

Related

Reference