3

コーディングを学ぶとき、変数の値をチェックするときに次のスタイルを教えられました。

int x;
Object *object;
...
if(x == 7) { ... }
if(object == NULL) { ... }

ifしかし、私が現場にいる今、私はステートメントのlhsとrhsを切り替えるアプローチを誓う複数の同僚に出会いました。

if(7 == x) { ... }
if(NULL == object) { ... }

理由は、の=代わりに誤って入力した場合==、コードはコンパイル時に失敗するということです。このスタイルに慣れていないので、読むの7 == xが難しく、コードの理解が遅くなります。

このスタイルを採用すれば、いつかバグのデバッグから身を守ることができるでしょうが、x = 7その間、誰かが私のコードを読むたびに、構文が非正統的であると恐れて時間を無駄にしている可能性があります。

その7 == xスタイルは業界で一般的に受け入れられ、読みやすいですか、それともこれは私の同僚の個人的な好みですか？

4

1 に答える 1

2

これは、誤って == の代わりに = を入力すると、コードがコンパイルに失敗するためです。

真実。一方、最新のC および C++ コンパイラ (これらの言語のいずれかを使用していると思いますか? あなたは言っていません) は、これを行うと警告を発すると思います。

使用しているコンパイラで試しましたか? デフォルトで実行されない場合は、それを誘発するために使用できるフラグがあるかどうかを確認してください。理想的には、単なる警告ではなくエラーにします。

たとえば、Microsoft C コンパイラを使用すると、次のようになります。

cl /Wall Test.c
test.c(3) : warning C4706: assignment within conditional expression

それはかなり明確です、IMO。(確かに、デフォルトの警告設定はそれを見つけません。)

このスタイルに慣れていないので、 7 == x を読むのが難しく、コードの理解が遅くなります。

それはそう。あなたのアプローチはより自然なスタイルであり、これを潜在的な問題として認識しないコンパイラーを実際に扱っていない限り (そしてそのコンパイラーを使用する以外に方法がない場合)、(IMO) を使用する必要があります。

編集: これはすべての言語で問題になるわけではないことに注意してください。すべての C ライクな言語でさえ問題ではありません。

たとえば、Java と C# のif構造は似ていますが、どちらの条件式もブール値に暗黙的に変換できる必要があります。割り当て部分はコンパイルされますが、最初の例の式の型は になりますint。これは、どちらの言語でも関連するブール型に暗黙的に変換できないため、コンパイル時のエラーが発生します。それでも問題が発生するまれな状況は次のとおりです。

if (foo == true)

タイプミスした場合：

if (foo = true)

コンパイルして間違ったことをします。MS C# コンパイラはそれについて警告しますが、通常はそのまま使用する方が適切です。

if (foo)

また

if (!foo)

可能であれば。それは次のようなものを残します：

if (x == MethodReturningBool())

対

if (MethodReturningBool() == x)

これはまだかなりまれであり、MS C# コンパイラ (およびおそらく一部の Java コンパイラ) ではまだ警告が表示されます。

于 2012-08-15T21:06:46.293 に答える