2

一部の人々、通常は C のバックグラウンドを持つ人々は、次のnullようにテストをコーディングします。

if (null == someVar)

「通常の」スタイルという信念で

if (someVar == null)

誤って次のようにコード化される可能性があります

if (someVar = null)

これは、 test forの代わりにaを誤って割り当ててしまいます。nullnull

ただし、次のようなミスコーディングがif (someVar = null)発生した場合:

  1. コンパイルするために、唯一の型someVarはBoolean
  2. コンパイルして実行すると、NullPointerException


なぜこれらの人々は、「守備的」(つまりスクリュー ボール) スタイルがまったく役に立たないことに気付いていないのですか?

ところで、パフォーマンスの問題として、コーディングif (null == someVar)は実際には実行がわずかに遅くなります-正確には1命令遅くなります。その理由は、null比較のためにスタックにプッシュする必要があるためです。一方、「通常の」スタイルでは特別な「is null」命令が使用されます。


私は知っています...本当に質問ではありません。もっと暴言。でもそれを世に出したかった。「洞察力に欠ける」と思われる場合は、賛成票を投じてください。

ですが、もしご存知でしたらお聞きしたいです。

4

3 に答える 3

8

彼らはこの習慣を C から持ち帰っているので、

if (someInteger = 0)

C にはブール値がなく、整数しかないため (0 は false、その他のすべての整数は true)、有効なコードです。

if (somePointer = NULL)

C では NULL は 0 であるため、これも有効です。

したがって、C では、この構文は理にかなっています。

Java では、このバグは実行時にも発生する可能性があることに注意してください。

if (b = true)

それ以外の

if (b == true)

もちろん、優れた Java 開発者は上記のコードを書くことはありませんが、

if (b)
于 2012-12-24T10:50:22.343 に答える
3

書いif (null == someVar)ても問題ないのに、どうして？C/C++ のバックグラウンドからこの規則を採用した人々が、Java でも同じ規則を維持することは悪い考えではありません。特に、まだ C/C++ で書いている場合。そうしないと、1 つの共通の規則を使用する代わりに、2 つの言語に対して 2 つの異なる規則を使用する必要があります。

本当の悪い副作用のない習慣の単純な問題。

于 2012-12-24T10:54:25.420 に答える
0

次のように変数のスコープを設定すると便利な場合があります。

if(std::shared_ptr<X> p = q.lock())
{
    // q is valid, I can now use p.

    p->DoSomething();
}

q.lock() != 0 は TRUE と評価されます。q.lock() == 0 は FALSE と評価されます。上記のコーディング スタイルは、意図を明確にします。しかし、最近のコンパイラは意図しない代入を非常に巧妙に見つけているので、実際には必要ありません。昔はそうではありませんでした。

于 2012-12-24T10:55:56.710 に答える