He means typing a single = when you meant to type ==.

In mathematics, a single equals means comparison.  The concept of 
assignment is derived from that, through something like "the value of x 
for which the boolean expression x = <my expression> is true."  In C and 
languages derived from it, = means assignment and == is comparison. 
However, it's easy to fall back in the old habits that we learned over 
many years of high school and university, and say something like:

if (a = 5) ...

when you meant to say

if (a == 5) ...

Most compiler will warn when you do this, so if you try to ensure your 
code has zero warnings, you'll notice when it warns you about the mistake.

However, if you always put the constant on the left, then when you leave 
out the other equals, you get this:

if (5 = y)

which won't compile.

I once saw someone's signature file that contained:

// World's last bug
if (red_button_pressed = 1)
    launch_missile();

Best,
Martin

Phil Henshaw wrote:
> Giles,
> 
> Can you explain what that causes?  You say "is prone to accidental
> assignment".  Sounds like variables erroneously change value when
> queried.  That's not good.   My limited experience is different, that
> code has all kinds of unexpected and hidden structure because it was
> written by people like me who can't keep a few dozen simple logical
> steps straight when interacting with few dozen others written by someone
> else  (i.e. there's confusion lying all around).  Is that also why
> variables are accidentally reassigned?   Or something different?
> 
> Ok, so then what happens after that?   You don't just come to the wrong
> answers it seems, but frequently trigger a cascade of mismatching stuff
> that sometimes gets 'trapped' and sometimes not?   Would you describe it
> differently?   
> 
>> About the only useful discovery I've made along these lines:
>>
>> Never do this:
>>
>> if @var == "Value"
>>
>> Always do this:
>>
>> if "Value" == @var
>>
>> the reason is because, if you screw up and only put in one 
>> equals sign, pretty much every language out there is prone to 
>> accidental assignment-during-test bugs, but no languages that 
>> I'm aware of are prone to accidental 
>> assigning-new-values-to-literals bugs.
>>
>> For what it's worth...
>>
>> -- 
>> Giles Bowkett
>> http://www.gilesgoatboy.org
>>
>> ============================================================
>> FRIAM Applied Complexity Group listserv
>> Meets Fridays 9a-11:30 at cafe at St. John's College
>> lectures, archives, unsubscribe, maps at http://www.friam.org
>>
>>
> 
> 
> 
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> lectures, archives, unsubscribe, maps at http://www.friam.org

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org

Reply via email to