Comparison Style

[llanitedave]

Given that

s = some static value
i = a value incremented during a loop

I'm used to comparing them as

if i == s:
# some code

But for some unknown reason I did a switch

if s == i:
# same code

It didn't seem to make any difference at first glance, so I just got to wondering --

Is there a standard for comparison order? Is there any kind of performance difference? Is there even a tradition for one or the other? Are there any gotchas?

Do I need to get a hobby?

 

[Chris Angelico]

Given that

s = some static value
i = a value incremented during a loop

I'm used to comparing them as

if i == s:
# some code

But for some unknown reason I did a switch

if s == i:
# same code

It didn't seem to make any difference at first glance, so I just got to wondering --

It won't make any difference in any sort of sane code. If there's any
situation in which == is not reflexive, something seriously nasty is
going on.

Is there a standard for comparison order? Is there any kind of performance difference? Is there even a tradition for one or the other? Are there any gotchas?

It's conventional to compare variables to constants, not constants to
variables (even in C where there's the possibility of mucking up the
operator, most people still compare variables to constants). I'd
normally use "i == s" there, treating s as a constant for the purpose
of the loop. Unless you're deliberately being poetical, language such
as "Three is the number thou shalt count" is distinctly abnormal, so
saying "if (5 == i)" is equally awkward. It's nothing major; mostly
it's like the algebraic convention of putting the more-known elements
earlier in a term (eg 2ðix - 2 is known, 3.14159.... is mostly known,
i is imaginary but at least it's constant, and x is unknown).

Do I need to get a hobby?

I thought programming WAS a hobby?

ChrisA

 

[llanitedave]

It won't make any difference in any sort of sane code. If there's any

situation in which == is not reflexive, something seriously nasty is

going on.






It's conventional to compare variables to constants, not constants to

variables (even in C where there's the possibility of mucking up the

operator, most people still compare variables to constants). I'd

normally use "i == s" there, treating s as a constant for the purpose

of the loop. Unless you're deliberately being poetical, language such

as "Three is the number thou shalt count" is distinctly abnormal, so

saying "if (5 == i)" is equally awkward. It's nothing major; mostly

it's like the algebraic convention of putting the more-known elements

earlier in a term (eg 2Ï€ix - 2 is known, 3.14159.... is mostly known,

i is imaginary but at least it's constant, and x is unknown).

Thanks, Chris. That's kind of along the lines of what I was thinking. Visually, the code just looked wrong, and I figure if for no other reasons than readability it's preferable in the traditional way.

It's nice to know, though, that the next time dyslexia strikes it's not necessarily a horrible thing.

I thought programming WAS a hobby?

I meant a safer, easier, and more mainstream hobby, like base jumping or motorcycle aerobatics or something.

 

[Chris Angelico]

I meant a safer, easier, and more mainstream hobby, like base jumping or motorcycle aerobatics or something.

Good point. With the sort of thinking you're demonstrating here, you
should consider a job working with Spike Milligna (the well-known
typing error). I believe there ought to be an office cubicle available
for you in one of the excellent organizations devoted to Milliganesque
thinkers and computer programmers - the walls are nicely padded...

ChrisA

 

[Steve Simmons]

With the sort of thinking you're demonstrating here, you
should consider a job working with Spike Milligna (the well known typing error).

Errr , I think you'll find that he's joined the choir invisibule. Mind you, he did say he was ill!

Sent from a Galaxy far far away

 

[llanitedave]

With the sort of thinking you're demonstrating here, you

should consider a job working with Spike Milligna (the well known typing error).



Errr , I think you'll find that he's joined the choir invisibule. Mind you, he did say he was ill!



Sent from a Galaxy far far away

Did you ever hear him sing? He's better off in the choir inaudible.

As am I...

 

[Neil Cerutti]

Did you ever hear him sing? He's better off in the choir
inaudible.

Well I've never heard either one.

 

[Steve Simmons]

Mind you, he did say he was ill!


Did you ever hear him sing? He's better off in the choir inaudible.

As am I...

The Ying Tong song - a classic of its time. But eminently suited to the chorally challenged.

Sent from a Galaxy far far away

 

[Dennis Lee Bieber]

It won't make any difference in any sort of sane code. If there's any
situation in which == is not reflexive, something seriously nasty is
going on.


It's conventional to compare variables to constants, not constants to
variables (even in C where there's the possibility of mucking up the
operator, most people still compare variables to constants). I'd
normally use "i == s" there, treating s as a constant for the purpose
of the loop. Unless you're deliberately being poetical, language such
as "Three is the number thou shalt count" is distinctly abnormal, so
saying "if (5 == i)" is equally awkward. It's nothing major; mostly
it's like the algebraic convention of putting the more-known elements
earlier in a term (eg 2ðix - 2 is known, 3.14159.... is mostly known,
i is imaginary but at least it's constant, and x is unknown).

The main reason for /literal/ first is to trap C/C++ assignment as
expression.

if (x = 5)

ends up assigning x the value 5 and THEN, since 5 is "true" executing
the "then" part.

if (5 = x)

OTOH is a compiler error.

But since Python doesn't allow assignment/binding as an expression,
either would be flagged an error.

 

[Dave Angel]

On 04/25/2013 10:48 PM, Chris Angelico wrote:

Also, this protection helps only when the "constant"
is actually something the compiler knows is a constant - it doesn't
work in a search function, for instance:

char *strchr(char *string, char findme) {
while (*string) {
if (*string==findme) return string;
++string;
}
return 0;
}

Sure, but if I were coding in C again, I'd have made that function signature

char *strchr(char *string, const char findme) {
or maybe
char *strchr(const char *string, const char findme) {

If you switch the order of operands in that, the compiler won't help
you.

Yes, it would.

Plus it "reads" wrong. So the convention is still
variable==constant.

In my case, after having it drilled in that you're "supposed" to put the
constant first, I realized that I never had any problem with using =,
because as soon as I questioned the order, I just double-checked that I
was using ==. At that point, there was no longer any benefit to making
the order backwards.

 

[Mark Lawrence]

The Ying Tong song - a classic of its time. But eminently suited to the
chorally challenged.

Released on a classic EP with Major Dennis Bloodnok's Rock and Roll Call
Rumba, I'm walking Backwards for Christmas and Bluebottle Blues.

Bravado, bravado. What a voice! (What a bank balance!)

 

[Roy Smith]

If you switch the order of operands in that, the compiler won't help
you. Plus it "reads" wrong. So the convention is still
variable==constant.

I just found a nice example of putting the constant first. I've just
done a whole bunch of ugly math to find some slice limits. To make sure
they're sane, I'm writing:

assert 5 <= i < j < original_song_count

I can't think of any way to write that which would be as clean and easy
to read.

 

[Terry Jan Reedy]

I just found a nice example of putting the constant first. I've just
done a whole bunch of ugly math to find some slice limits. To make sure
they're sane, I'm writing:

assert 5 <= i < j < original_song_count

I can't think of any way to write that which would be as clean and easy
to read.

Chained comparisons like this are standard math notation, which is why
Python 'does the right thing' with them.