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

  • Thread starter Thread starter Guest
  • Start date Start date
G

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.
 
Stano said:
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?
Click to expand...

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?
Click to expand...

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.
 
Ah, it all becomes clear now. Cool. One less thing to wonder/worry about. Thanks for the clarification.
 
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.
 
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.
Click to expand...

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.
 
He said it's not INcorrect Alvin. :)

Alvin Bruney said:
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.
Click to expand...
 
Trilok Khairnar said:
Suppose you ever go back to write a C program, the habit of writing (null ==
something) would save you some trouble.
Click to expand...

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.
Click to expand...

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.
 
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.
 
you have to admit that no harm is done in this construct.
Click to expand...

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.
Click to expand...

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.
 
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.
Click to expand...

It isn't natural to you because you aren't from the c++ world, but still you
make a valid point.
 
well, i come from the c++ world and it is normal to me.
Click to expand...

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.
Click to expand...

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.
 
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
 
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.
 
Christian Boult said:
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" );
Click to expand...

So write it as the (more natural, IMO)

if (a)
{
Console.WriteLine("allo");
}
You just assigned true to a and the if statement passes.
Click to expand...

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.
Click to expand...

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.
 
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.
 
Christian Boult said:
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.
Click to expand...

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...
Click to expand...

Exactly.
 
Thomas W. Brown said:
Actually, there is one difference between the two... If "something" is a
Click to expand...
class that overrides operator ==, then
if (null == something)

will always be a quick object reference comparison returning 'true' when
Click to expand...
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
Click to expand...
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).
 
Back
Top