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

[Guest]

I frequently see .NET coders, especially C# coders, use the following syntax:

if (null == something){DoSomething();}

instead of the much more intuitive

if (something == null) {DoSomething();}

Is this an example of anally-retentive programming held over from some bygone C era, or are there actual benefits to using this syntax in the .NET world?

I would have thought a modern compiler would not care about syntax order, as it would optimize such a statement to produce the best execution speeds. Can anyone enlighten me?

Thanks,

Stano.

 

[Jon Skeet [C# MVP]]

I frequently see .NET coders, especially C# coders, use the following syntax:

if (null == something){DoSomething();}

instead of the much more intuitive

if (something == null) {DoSomething();}

Is this an example of anally-retentive programming held over from
some bygone C era, or are there actual benefits to using this syntax
in the .NET world?

The former, I believe.

I would have thought a modern compiler would not care about syntax
order, as it would optimize such a statement to produce the best
execution speeds. Can anyone enlighten me?

Everyone I've asked about it has basically said it's a habit from C/C++
days, where they wanted to avoid the typo of

if (something = null)

Some didn't know that in C# that's not legal code, and others just
preferred to stick to their existing habits.

 

[Guest]

Ah, it all becomes clear now. Cool. One less thing to wonder/worry about. Thanks for the clarification.

 

[Trilok Khairnar]

Suppose you ever go back to write a C program, the habit of writing (null ==
something) would save you some trouble.
Besides, it's not incorrect in C#. And IMHO, it suggests that the programmer
gives a thought to how a construct would work in some other language.

Regards,
Trilok.

 

[Alvin Bruney [MVP]]

Besides, it's not incorrect in C#. And IMHO, it suggests that the

programmer
gives a thought to how a construct would work in some other language.

why do you think it is not correct?

The compiler accepts it as valid code. I haven't seen a recommendation
against its use and frankly i wouldn't support one because the code is clear
and unambiguous inspite of the fact that it comes from another language.

 

[Daniel Billingsley]

He said it's not INcorrect Alvin.

why do you think it is not correct?

The compiler accepts it as valid code. I haven't seen a recommendation
against its use and frankly i wouldn't support one because the code is clear
and unambiguous inspite of the fact that it comes from another language.

 

[Alvin Bruney [MVP]]

Oops. that's what i get for half glancing a response.

thanks for jumping me on that

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok

He said it's not INcorrect Alvin.

 

[Jon Skeet [C# MVP]]

Suppose you ever go back to write a C program, the habit of writing (null ==
something) would save you some trouble.

If I change language, I precisely *don't* want my code to look as if
it's in the previous language - otherwise I'm likely to adopt the same
idioms and "think" in the previous language, which is a very bad idea.
Some of the worst Java I've seen was written by people who were trying
to make it C++, and I'm sure the same would be true if I tried to write
C as if it were C#.

Besides, it's not incorrect in C#. And IMHO, it suggests that the
programmer gives a thought to how a construct would work in some
other language.

Whereas IME, it suggests that the programmer *hasn't* given a thought
as to whether an idiom which is usually regarded as sacrificing some
readability for typo-safety is still necessary in the new language.

 

[Alvin Bruney [MVP]]

Jon,
you have to admit that no harm is done in this construct. It doesn't hurt
readability, it certainly isn't contrary to any recommended practice. It is
probably only a matter of programmer taste.

 

[Jon Skeet [C# MVP]]

you have to admit that no harm is done in this construct.

I admit that no *semantic* harm is done.

It doesn't hurt readability, it certainly isn't contrary to any
recommended practice. It is probably only a matter of programmer
taste.

No, I believe it *does* hurt readability. I believe it's an unintuitive
way of writing the code (as did the OP, btw) which people only ever did
in C/C++ to avoid typos. Tell me, do you think anyone would have done
it if there *hadn't* been the potential for syntactically correct but
semantically disastrous errors in C/C++? I don't.

Writing code in the most natural way is a good thing. This *isn't*
writing code in the most natural way - it's writing code in a way which
was developed to avoid a problem in a different language.

 

[Alvin Bruney [MVP]]

well, i come from the c++ world and it is normal to me.

Writing code in the most natural way is a good thing. This *isn't*
writing code in the most natural way - it's writing code in a way which
was developed to avoid a problem in a different language.

It isn't natural to you because you aren't from the c++ world, but still you
make a valid point.

 

[Jon Skeet [C# MVP]]

well, i come from the c++ world and it is normal to me.

But only because the idiom is common there to avoid typos - not because
it's a fundamentally readable style.

It isn't natural to you because you aren't from the c++ world, but still you
make a valid point.

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.

 

[Alvin Bruney [MVP]]

ya, when you put it like that it is hard to argue against.

 

[Thomas]

First, my opinion: I don't care what language you are from, it isn't
natural in terms of how we, as people, process logic.

Either way is correct synatically, but I've seen this screw up too
many simple conditions. For example -- and this is purely example, no
real usage for this. Look at this for no more than 5 seconds and tell
me what it does:

do{
//some logic, perhaps generating a random sentence.
MyString += GetARandomCharacter();
} while (0>MyString.IndexOf("."));

Maybe you got it, maybe you didn't. But wouldn't it make sense to say
something like:

do{
MyString += GetARandomCharacter();
} while (MyString.IndexOf(".") == -1);

I know it's hard to quantify a bogus code sample. I've read a lot of
coding books and I understand best practices; and in my opinion (no
more valid than anyone else's, of course) I just think the paramount
concern should be readability. I try to think, "OK, what's the next
guy who looks at this code going to think when reading it for the
first time?"

OK, I'm done!

Tom

 

[Christian Boult]

The real reason I saw from other's coding practices is to eliminate the
following possible error :

bool a = false;
if ( a = true ) Console.WriteLine( "allo" );

You just assigned true to a and the if statement passes.

But if you wrote

if ( true = a ) Console.WriteLine( "allo" );
You get a compilation error -- cannot assign to a constant expression.

So in the same vein writing if ( null == something ) is just in keeping
with the idea that you write the constant expression on the left and make
sure the compiler catches such possible mistake.

Chris.

 

[Jon Skeet [C# MVP]]

The real reason I saw from other's coding practices is to eliminate the
following possible error :

bool a = false;
if ( a = true ) Console.WriteLine( "allo" );

So write it as the (more natural, IMO)

if (a)
{
Console.WriteLine("allo");
}

You just assigned true to a and the if statement passes.

Yup. And I can't remember the last time I wrote a conditional comparing
the value of a variable with a boolean constant in that way.

But if you wrote

if ( true = a ) Console.WriteLine( "allo" );
You get a compilation error -- cannot assign to a constant expression.

So in the same vein writing if ( null == something ) is just in keeping
with the idea that you write the constant expression on the left and make
sure the compiler catches such possible mistake.

Except the compiler catches is for every type other than boolean
already:

if (something=null)

won't compile in C#. The equivalent would in C/C++, which is where the
practice comes from - but aside from the incredibly rare occasions
where you're comparing the value of a boolean variable with a constant,
it's pointless and reduces readability.

 

[Christian Boult]

I'm not saying that's what I write...
It's absolutly ugly....
That's just what I saw as guidelines from other 3rd party developers...
It feels weird and unatural to me, but I did see this as a guideline in more
than one place and that was the reason that was given.

Yuck...

Chris.

 

[Jon Skeet [C# MVP]]

I'm not saying that's what I write...
It's absolutly ugly....
That's just what I saw as guidelines from other 3rd party developers...
It feels weird and unatural to me, but I did see this as a guideline in more
than one place and that was the reason that was given.

It's a reasonable guideline in C/C++, although normally you can
encourage the compiler to warn you if it looks like you've done it
accidentally. In C#, however, it's an abomination.

Yuck...

Exactly.

 

[Alvin Bruney [MVP]]

perhaps the better thing is to dump C++.

ya ya i know that wasn't called for...

 

[Daniel Billingsley]

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.

The "slight improvements" would be measured in nanoseconds - hardly worth
sacrificing readability (assuming you find the latter more readable).