Is it (null == something) or (something == null)?

[Jon Skeet [C# MVP]]

Actually, there is one difference between the two... If "something"
is a class that overrides operator ==, then

if (null == something)

will always be a quick object reference comparison returning 'true'
when something is a null reference and 'false' when not.

But,

if (something == null)

will, if something is not null, be calling a subroutine only to do
the comparison against null and return false. Performance-wise, then,
the first version might offer slight improvements.

No, they'll both call the overloaded operator. See section 14.2.4 of
the C# language specification for details.

Here's a test program to show that happening:
using System;

class Foo
{
public static bool operator == (Foo y, Foo x)
{
return true;
}

public static bool operator != (Foo y, Foo x)
{
return false;
}

public override int GetHashCode()
{
return 0;
}

public override bool Equals (object o)
{
return true;
}
}

public class Test
{
static void Main()
{
Foo x = new Foo();

if (x==null)
{
Console.WriteLine("Hello");
}

if (null==x)
{
Console.WriteLine("Hello");
}
}
}

 

[Guest]

[snip]

Never mind, I was wrong... as John points out, the two really are the same.

-- Thomas Brown

 

[Daniel Billingsley]

You might want to rethink the nanoseconds throw-away comment, too. In my

admittedly small .NET/C# experience (just a year now) I have found the
environment to be no more (if not even *less*) forgiving of poor programming
practices with regard to performance than unmanaged C or C++.

Your comments are fair enough, but just for the record it wasn't a
throw-away comment. It was based on an article written by someone who
actually took the time to measure performances differences for things like
inlining vs. making a method call and other things like that. The
differences were in the nanosecond realm. Similar to the differences I have
found in comparing alternative ways of doing things in cases where one of
them is supposed to be a terrible performer. It's why I am unashamed to use
string.Format() when it makes cleaner code even though I know it is a
relative performance dog.

Most of the time I'm writing code where it can't possibly make a significant
difference, like in a database app where that's all buried in the relative
eon of the data access. It's the old trying to remove the speck from the
other guy's eye while there's a log in yours.

But as we now know, it's all moot anyway in this case. Peace.

 

[Alvin Bruney [MVP]]

No, they'll both call the overloaded operator. See section 14.2.4 of

the C# language specification for details.

do you have to quote the specs? .

 

[Jon Skeet [C# MVP]]

do you have to quote the specs? .

I think it's usually a good idea - otherwise it comes down to "well, it
doesn't work that way in my test program" which isn't a terribly good
argument, IMO.

 

[Guest]

You aren't serious about performance enhancements are you? Modern optimizing compilers will negate any imagined performance enhancements you may hope to derive from the way you organize your statements.

If you want this level of control, disable optimizations when you compile, or write in assembler! Hey, about about a .NET compiler for assembly language (sic) ?

 

[Mike Newton]

I'd have to say that it's fine that you think that way. Then again, you
are not the wise one who gets to define what readability is, or what the
most *natural* way of writing code is. Just think about this: How is
written C# code natural anyway? It's man-made, and therefore whatever
*works* for someone *is* most natural.

This whole argument is relatively stupid. It's like complaining about
those who use the incorrect brace style, since there is only One True
Brace Style.

 

[Mike Newton]

Jon Skeet [C# MVP] wrote:
***blah***

I think the clincher is to ask yourself how you'd read the meaning of
the line of code out loud to a colleague in an informal way. Suppose
you were tracing some code to work out what should happen, how would
you read out:

if (5==x)
{
DoSomething();
}
else
{
DoSomethingElse();
}

I'd read that out as "If x is 5, we call DoSomething, otherwise we call
DoSomethingElse". The idea of reading it as "If 5 is x, we call
DoSomething, otherwise we call DoSomethingElse" is very strange to me -
not in code terms, but in *English* terms. I don't know if there are
other natural spoken languages where it would be a natural way of
saying it - and if there are such languages, then native speakers of
those languages have much more reason to use the idiom. Otherwise, I
think it should be avoided in languages where it's not necessary for
safety's sake.

***blah***

If you are using the terminology "x is 5," you would be incorrect in any
case. It would be proper to say "x is equal to 5," which equivocates to
"5 is equal to x" very well.

Then again, the code would be much more legible if it were:

if (5 == x)
DoSomething();
else
DoSomethingElse();

All those line breaks between braces really cause a stutter in the flow
of the program (not to mention that braces are completely unnecessary in
this case).

--Just to give ya a hard time.

 

[Alvin Bruney [MVP]]

This whole argument is relatively stupid.

it's not. see how many responses came for what you considered stupid. It
means that different people see things differently. These differences lead
to ambiguous code which results in misbehaved programs.

 

[Jon Skeet [C# MVP]]

I'd have to say that it's fine that you think that way. Then again, you
are not the wise one who gets to define what readability is, or what the
most *natural* way of writing code is. Just think about this: How is
written C# code natural anyway? It's man-made, and therefore whatever
*works* for someone *is* most natural.

But it's not just about one person - it's about what works for
whoever's reading the code. I've talked to lots of people who agree
that the if (constant == variable) way of writing things is less
naturally readable than the other way round, but they do it anyway for
safety (in C/C++). That's fine. On the other hand, I have yet to meet
anyone who believes that it's actually *more* readable - the *only*
reason people use that convention is for safety, in my experience. That
means that in a language where the safety isn't required (or rather, is
obtained in other ways) the convention is counter-productive.

This whole argument is relatively stupid. It's like complaining about
those who use the incorrect brace style, since there is only One True
Brace Style.

I agree that the bracing style argument is relatively stupid - but only
because people can't agree on which is more naturally readable, and
there don't seem to have been objective studies done.

 

[Jon Skeet [C# MVP]]

If you are using the terminology "x is 5," you would be incorrect in any
case. It would be proper to say "x is equal to 5," which equivocates to
"5 is equal to x" very well.

If you're going to get picky, you should be talking about the *value*
of x. x itself is variable - its *value* is what we're talking about.
However, when reading code to myself in English, I would ignore the
distinction between the variable and its value, and assume the
equality. That's how English works for me. Even with your expanded
version, however, "x is equal to 5" is much more natural for me than "5
is equal to x". English idiom just doesn't compare constants that way -
you don't say, "If Wednesday is today", you say "If today is
Wednesday".

Then again, the code would be much more legible if it were:

if (5 == x)
DoSomething();
else
DoSomethingElse();

All those line breaks between braces really cause a stutter in the flow
of the program

Not to my eyes, which can much more easily ignore symbols than reorder
things.

(not to mention that braces are completely unnecessary in
this case).

They're unnecessary, but they're a bit like the "safety" version of
comparisons in C - they avoid mistakes. They mean that:

1) It's obvious that the line is the "thing to do" if the comparison
matches. Often if you have a multi-line condition, it's not obvious
where the condition ends and the "thing to do" starts, without braces.

2) It makes it hard to make a mistake where you mean something to be in
the same code block, but it doesn't appear in the code block.

There are plenty of code convention documents around suggesting the
uniform use of braces, regardless of whether they're strictly necessary
- it's not just my idea...

 

[Ken Allen]

Remember that the original reason for using the form
if (5 == x) { y = 6; }
was to avoid the coding error in C/C++ that reports no errors:
if (x = 5) { y = 6; }
The later construct contains an assignment inside the 'if', and the
assignment results in a non-zero value, which is treated as true, and so the
assignment to the 'y' variable always takes place. The convention of placing
the constant on the left side of expressions inside 'if' statements was to
avoid this side-effect. While many compilers would report this as a warning,
most developers were forced not to use the compiler setting that would
report this, especially in the MS world since MFC reported so many warnings
and errors.

So this was a convention that resulted from the state of the language, the
compilers and the development environments. In a UNIX project, for example,
we used a compiler that enable this specific situation to be reported as an
error, and so the convention of placing the constant on left of the
expression was not required.

With VB and C# this convention is not required -- it only applies to C and
C++ where the language itself permits assignment within the 'if' statement
expression.

-ken

 

[Trilok Khairnar]

If you're going to get picky, you should be talking about the *value*
of x. x itself is variable - its *value* is what we're talking about.
However, when reading code to myself in English, I would ignore the
distinction between the variable and its value, and assume the
equality. That's how English works for me. Even with your expanded
version, however, "x is equal to 5" is much more natural for me than "5
is equal to x". English idiom just doesn't compare constants that way -
you don't say, "If Wednesday is today", you say "If today is
Wednesday".

Nicely and convincingly put John. I agree that 'constant == variable' is
less 'natural' though it is as 'readable'.
However, One can read 'constant == variable' and interpret it as 'variable
is constant'.

Everytime I see a line of code with 'constant == variable', it shocks me for
a second while glancing over,
and then I tell myself 'This style that appears less natural was followed as
a safety mesure.' and proceed to the next line.

If one does not program in C, C++, I agree that it's a good idea to use the
more 'natural' syntax.

Regards,
Trilok.

 

[Jon Skeet [C# MVP]]

Nicely and convincingly put John. I agree that 'constant == variable' is
less 'natural' though it is as 'readable'.
However, One can read 'constant == variable' and interpret it as 'variable
is constant'.

Ah, but that takes extra effort.

Everytime I see a line of code with 'constant == variable', it shocks me for
a second while glancing over,

Indeed - and that mental jolt means it's harder to read, IMO. Not
*much* harder to read, but it makes a sufficient difference to make it
worth avoiding where it's unnecessary.

and then I tell myself 'This style that appears less natural was followed as
a safety mesure.' and proceed to the next line.

If one does not program in C, C++, I agree that it's a good idea to use the
more 'natural' syntax.

Goodo

 

[Matt Berther]

Hello Alvin Bruney [MVP]" vapor at steaming post office,

He never stated that it was incorrect... He said that it was *not* incorrect, meaning correct. :=)

Read in context, it seems as he actually supports the idea..