1

ばかげた質問かもしれませんが、好奇心に負けてしまいました。最近、関係演算子の式の順序を「逆」にしているように見えるコードを見てきました。

if (0 == someVariable)

私が通常見たり書いたりするものとは対照的に:

if (someVariable == 0)

私には、2 番目の方法の方が読みやすく直感的に見えるので、最初の方法が表示されている理由があるのではないかと考えています。論理的には、両方のステートメントが同じ結果に評価されるので、どのように記述されるかは個人的な好みの問題でしょうか?

4

6 に答える 6

6

これは個人的な好みであることを理解しています。ただし、変数を 2 番目に配置することで、c 開発者を悩ませていた変数に誤って定数を割り当てないようにすることができます。これがおそらく、開発者が言語を切り替えるときに c# で表示される理由です。

于 2008-09-18T12:20:19.507 に答える
2

順序は問題ではありませんが、前者はチェックしているゼロであることを意味します。規約により、後者の使用が規定されています。

于 2008-09-18T12:19:35.843 に答える
2

C および C++ の主な理由は、入力が簡単だからです。

if (someVariable = 0) {
    ...
}

これは常に失敗し、someVariable0 に設定されます。

==個人的には変数優先のスタイルの方が自然に読めるので好きです=

多くの C および C++ コンパイラは、 内に定数を割り当てると警告を発行しますififJava と C# では、句で非ブール式を禁止することにより、この問題を回避しています。Python では、代入を式ではなくステートメントにすることで、この問題を回避しています。

于 2008-09-18T12:22:05.133 に答える
1

最初の方法は、一部の言語 (C/C++) で悲惨な結果をもたらす可能性がある IF ステートメントで代入を行わないように注意する方法として存在します。C# では、ブール値を設定している場合にのみ、これに噛まれます。

潜在的に致命的な C コード:

if (succeeded = TRUE)
{
    // I could be in trouble here if 'succeeded' was FALSE
}

C/C++ では、VAR == CONSTANT を意図した場合、どの変数もこの VAR = CONSTANT の問題の影響を受けやすくなります。そのため、IF ステートメントの順序を変更してコンパイル エラーが発生するようにするのが一般的です。

if (TRUE = succeeded)
{
    // This will fail to compile, and I'll fix my mistake
}

C# では、ブール式のみが if ステートメントで有効であるため、これの影響を受けやすいのはブール値のみです。

if (myInteger = 9)
{
    // this will fail to compile
}

したがって、C# の世界では、慣れていない限り、CONSTANT == VAR スタイルを採用する必要はありません。

于 2008-09-18T12:20:08.790 に答える
1

平等に加えて、次のようなコードに出くわすことがよくあります

if (0 > number)

また

if (NULL != pointer)

C/C++ で間違いを犯す危険すらありません。これは、善意の教え方が明らかに悪い習慣になってしまった状況の 1 つです。

于 2008-09-18T12:52:24.093 に答える
1

後者の形式は C 構文の残り物であり、不注意で等号の 1 つを省略した場合、比較ではなく代入を行います。

ただし、もちろん数値リテラルに代入することはできませんので、2 番目の例のように記述した場合、バグではなくコンパイラ エラーが発生します。

ただし、C# では、これを誤って行うことはできないため、実際には問題になりません。

于 2008-09-18T12:21:33.123 に答える