Order of parameters in if statement - is it just style or is there areason

[ssg31415926]

In the past, in other languages, I was taught to write tests like
this:

if (bob == "fool")
:

sometimes, in code samples, I see:

if ("fool" == bob)
:

Is there a reason for this (to me) reversal in C# or is it just a
house-style thing?

Please note, I'm not necessarily talking about string comparisions,
just the order between the object/value being tested and the
comparison object/value.

 

[Adam Sandler]

if ("fool" == bob)

That actually compiles? I'm not in front of my IDE right now but
wouldn't it be reasonable to think one would get an error for
assigning a primitive to a literal?

 

[Jon Skeet [C# MVP]]

That actually compiles? I'm not in front of my IDE right now but
wouldn't it be reasonable to think one would get an error for
assigning a primitive to a literal?

There's no assignment there - it's == rather than =.

Jon

 

[Jon Skeet [C# MVP]]

In the past, in other languages, I was taught to write tests like
this:

if (bob == "fool")
:

sometimes, in code samples, I see:

if ("fool" == bob)
:

Is there a reason for this (to me) reversal in C# or is it just a
house-style thing?

I usually see this from people who were brought up with C (and
compilers which weren't as helpful as they might be).

In C, this is entirely valid, but almost never what the programmer
wants:

if (i=0)

whereas this is invalid:

if (0=i)

So to prevent typos (= instead of ==) from producing syntactically
valid but incorrect code, people use the "constant == value" style.

In C# this is unnecessary, with the one exception being comparing
booleans:

if (condition = true)

is valid but almost certainly wrong. I'd always write if (condition)
or if (!condition) anyway, so it doesn't actually come up anyway...

The if (variable == constant) style is more readable in my view. Ask
authors of the if (constant == variable) style if they've got a
genuine reason *which is valid for C#* - chances are they haven't, and
they're just using an idiom from another language.

Jon

 

[Marc Gravell]

Well, in some languages that order is useful to force a warning/error if
you have used = (assignment) instead of == (equality test), since most
types can be evaluated as bools (generally meaning non-zero).

In C#, this isn't usually as much of a problem; most things can't be
evaluated as bools, and even if they can the compiler spits out a
warning in some (but not all) of the possible ways of getting it wrong.

Personally I find the if(var == value) way more intuitive to read, but I
can't say it causes me distress either way...

Marc

 

[Adam Sandler]

There's no assignment there - it's == rather than =.

Wouldn't .Equals be the proper way then?

 

[Jon Skeet [C# MVP]]

Wouldn't .Equals be the proper way then?

No:
a) It's less readable
b) It throws an exception if the LHS is null (unless you use
object.Equals)

This isn't Java - the String type overloads ==

Jon

 

[Marc Gravell]

Well, first off, a==b is a lot quicker to type and read than
a.Equals(b), but is also type-safe; since there is an instance "bool
Equals(object)" method on object, the following will compile:

FileStream fs; // TODO
if("42".Equals(fs)) {...}

Which is clearly gibberish. The following (correctly) does not compile:

if(42 == fs)

Operator '==' cannot be applied to operands of type 'int' and
'System.IO.FileStream'

Also, you'd then need to be *very* careful about whether a is null,
where-as the == operator can deal with this internally. Of course, there
is object.Equals(a,b) but that involves boxing - as does a.Equals(b) if
a doesn't provide an overload for the correct type of b.

Marc

 

[Adam Sandler]

This isn't Java - the String type overloads ==

That's odd... there's a page on wikipedia which says Java was created
with C#'s features in mind.

 

[Duggi]

In the past, in other languages, I was taught to write tests like
this:

if (bob == "fool")
:

sometimes, in code samples, I see:

if ("fool" == bob)
:

Is there a reason for this (to me) reversal in C# or is it just a
house-style thing?

Please note, I'm not necessarily talking about string comparisions,
just the order between the object/value being tested and the
comparison object/value.

I think I can give an other view to this...

I have seen the people who migrated from C to C++ to C#. So a little
history behind it is.....

Once upon a time there was C, C++....

if(var = constant) is perfectly valid, where constant/expression will
be assigned to var and then does a bool operation for if. When == is
been introduced for comparison, still programer tend to use if(var =
con/exp) instead of if(var == con/exp). As both the cases are
perfectly valid syntatically, however semantics change. So it was
taken a good practice that when a var is supposed to be compared with
a const/expression, the if stantement should be (not a must) if(const/
exp == var) sothat even by habit programmer types in = instead of ==
compiler catches the error.

When the programmers migrated to C++ to C#, the habits also migrated,
so now and then I still see some programmers in C#, who writes
if(constant / expression == variable) .....

Hope I am clear.



-Cnu

 

[Cor Ligthert[MVP]]

I think it is just an expression

A fool is Bob?
is in my way of speaking not the same as
Bob is a fool?

However in C# it is the same so it does not make much sense in my idea,
however can be seen as a piece of documentation as the only fool there would
be is Bob.

Cor

 

[Jon Skeet [C# MVP]]

I think it is just an expression

A fool is Bob?
is in my way of speaking not the same as
Bob is a fool?

No, because "is a" isn't a commutative relationship. Equals is meant
to be.

"foo" is string
makes sense in C#, but
string is "foo"

doesn't. The original post wasn't asking whether Bob was a fool. It
was asking whether the value of the string variable named bob was
equal to the sstring literal "fool". They're very different questions.

However in C# it is the same so it does not make
much sense in my idea,
however can be seen as a piece of documentation
as the only fool there would be is Bob.

The same logical fallacy applies - you're trying to treat equality as
"set inclusion" which it certainly isn't.

Jon

 

[Cor Ligthert [MVP]]

OK, then

(Bob == "fool") ?

is for you the same as

("fool" == Bob ) ?

In my logical thinking there is a difference.

However is the difference between you and me, for you in both cases is the
question if Bob is a fool.

For me the first one is a question if Bob is a fool, the second one is a
question if the fool is Bob.



Cor

 

[Marc Gravell]

For me the first one is a question if Bob is a fool, the second one is a

question if the fool is Bob.

I'd have to agree with Jon; that doesn't ask whether "Bob is a fool".
It is closer (but not quite) to:

* I have a Bob; I have a "fool"; are they the same?

And to me, that is the same questions as (commutative with):

* I have a "fool"; I have a Bob; are they the same?

The question to "Bob is a fool" is a different question, something
like "Bob.IsFool" (property) or "Bob is Fool" (inheritance) - but
nothing to do with an equality test.

Marc

 

[Jon Skeet [C# MVP]]

OK, then

(Bob == "fool") ?

is for you the same as

("fool" == Bob ) ?

Absolutely. Assuming Bob is a string variable (and correct
implementation of string's == overload), the above expressions always
evaluate to the same value.

In my logical thinking there is a difference.

Then you're trying to apply natural language to *code*. The above
doesn't express "is Bob a fool". It expresses "is the value of the
variable Bob equal to the string "fool".

However is the difference between you and me, for you in both cases is the
question if Bob is a fool.

No, because again that's a matter of set inclusion rather than
equality.

For me the first one is a question if Bob is a fool, the second one is a
question if the fool is Bob.

You're trying to apply completely different operators than the ones
expressed in the code.

Jon

 

[Cor Ligthert[MVP]]

Jon,

I knew already this reply from you?



Cor

 

[Jon Skeet [C# MVP]]

I knew already this reply from you?

So you were just trolling?

Seriously, I don't see the point in deliberately twisting what the OP's
code was saying into something where the order of the operands matters.
It *doesn't* matter for equality, and equality was the operator in
question. Why talk about a different operator in the same context? It
just creates confusion, which is hardly constructive.

 

[Cor Ligthert[MVP]]

Jon,

So you were just trolling?

Seriously, I don't see the point in deliberately twisting what the OP's
code was saying into something where the order of the operands matters.
It *doesn't* matter for equality, and equality was the operator in
question. Why talk about a different operator in the same context? It
just creates confusion, which is hardly constructive.

Read it again what you wrote and try to mathematical extract it, then you
will see that it was not me who is trolling.

Be aware that you don't get any reply in this thread from me anymore.

Cor

 

[Jon Skeet [C# MVP]]

Read it again what you wrote and try to mathematical extract it, then you
will see that it was not me who is trolling.

I have always been consistent in my treatment of the OP's expression
as equality, which is what the code means. You have taken it to mean
something completely different. The question is about the order of the
operands in an equality expression - that order doesn't matter, but
the order of operands in the operators *you* have been discussing does
matter.

In other words, you have brought in different operators (set inclusion
in particular) which are irrelevant to the OP's actual question, but
which could easily introduce confusion.

My question is why you've done that.

Be aware that you don't get any reply in this thread from me anymore.

Relevance? It's not like you've been deluged with interested replies
from other folks either...

Jon

 

[Jon Skeet [C# MVP]]

Relevance? It's not like you've been deluged with interested replies
from other folks either...

Sorry, just reread the last bit of your post. Fair enough - I don't
think this thread was going anywhere in particular any more anyway.
I'd just ask that you try not to confuse matters by trying to
interpret code to mean something very different from what it actually
*does* mean.

Jon