Evaluation of complex conditions

[Ken Ray]

On Oct 6, 2011, at 11:40 AM, Pete wrote:

> Thanks Alex, makes total sense with the examples you provided.
> 
> The only remaining question in my mind is if the use of parens changes
> anything - a post yesterday suggested that putting a condition in parens
> causes it to be evaluated ahead of the other conditions but I can't make
> that happen in your example.  I suspect confusion between precedence and
> evaluation again.

There are certain times where parens are necessary (I just wish I could remember specifically where and when). It *is* a good practice to put expressions in parens for readability, especially when it comes to working with objects. Compare:

if the name of button 1 contains "test" and the name of button 2 contains "test" then

if (the name of button 1 contains "test") and (the name of button 2 contains "test") then

The second is definitely more readable. Personally, I put parens around most/all expressions since that is the way it is with most other languages. For example, we *can* do this:

if 2 + 3 = 5 then
  answer "Right"
else
  answer "Wrong"
end if

but if you try that the equivalent in JavaScript:

if 2 + 3 == 5 {
  alert("Right");
} else {
  alert("Wrong");
}

you won't get an alert dialog. You have to put the expression in parens to make it work:

if (2 + 3 == 5) {
  alert("Right");
} else {
  alert("Wrong");
}

So my suggestion is to parenthesize everything for both readability and developing a cross-compatible coding style, even if it doesn't affect (for LiveCode) how the engine parses the expression.


Ken Ray
Sons of Thunder Software, Inc.
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/