Hello,
Have you ever used nested DOIFs? (DOIFs inside DOIFs) When would you recommend using them? Do you have any tips on how to work with nested DOIFs effectively?
- Malkin
Dear Malkin,
I use nested conditions all the time: in CAOS, in PHP, Javascript, and ColdFusion (which is, interestingly, more similar to CAOS in some ways than it is to other web-related languages). The correct answer is: whenever it seems more efficient to do so. In general, which method you use isn't a matter of optimization, but basic logic that depends entirely on the circumstances: your script won't do what you want it to if you use the wrong method.
But there are definitely some times when it's better to nest them, and some times when it isn't. The most common alternative to nesting conditions is to link them, like this:
DOIF condition 1
(do something)
ELIF condition 2
(do something)
ELIF condition 3
(do something)
ELSE
(do something)
ENDI |
It's all essentially one "block" of conditions. If the first condition isn't true, it will automatically try the second, then if that isn't true it will try the third, etc.
Nesting conditions, as you know, looks like this:
DOIF condition 1
(do something)
ELSE
DOIF condition 2
(do something)
ELIF condition 3
(do something)
ELSE
(do something)
ENDI
ENDI
|
There are a few ways in which humans use conditions that computers don't, and this "language bias" is the most counterproductive when using conditions, because our experience speaking English (or German, or Chinese) influences how we expect CAOS to work. For instance, I see a lot of new programmers write stuff like this:
DOIF the sky is blue
(do something)
ELIF the grass is green
(do something)
ELSE
(do something)
ENDI |
Because we all think the same way and make the same initial assumptions when learning to code, you'll see people do this kind of thing in any programming language that uses conditions. The problem is that computers--regardless of what language you're using to communicate with them--don't like subject changes in the middle of condition blocks. Since the first DOIF is referring to the sky, the game expects that the next condition in the block will also relate to the sky. Even though the basic structure looks correct to the human eye, the code above won't work consistently because it relies on forcing the game to "think" in a way it wasn't designed to. This is the kind of situation in which we need to use nested conditions. The code above becomes much more stable and reliable when we "phrase" it properly:
DOIF the sky is blue
(the sky is blue, so do something)
ELSE
DOIF the grass is green
(the sky is not blue BUT the grass is green, so do something)
ELSE
(the sky is not blue AND the grass is not green, so do something)
ENDI
ENDI
|
Now the game will know for sure that we only care about the color of the grass if the sky is blue. If we want to check the color of the grass and take different actions depending on both the sky and grass color, we can duplicate the grass-related condition block like this:
DOIF the sky is blue
DOIF the grass is green
(the sky is blue AND the grass is green, so do something)
ELSE
(the sky is blue BUT the grass is not green, so do something)
ENDI
ELSE
DOIF the grass is green
(the sky is not blue BUT the grass is green, so do something)
ELSE
(the sky is not blue AND the grass is not green, so do something)
ENDI
ENDI
|
Or we can use variables to "tally up" the results of our conditions, like this:
DOIF the sky is blue
SETV VA00 1
ELSE
SETV VA00 2
ENDI
DOIF the grass is green
ADDV VA00 10
ELSE
ADDV VA00 20
ENDI
DOIF VA00 EQ 11
(the sky is blue and the grass is green)
ELIF VA00 EQ 12
(the sky is blue but the grass is not green)
ELIF VA00 EQ 21
(the sky is not blue but the grass is green)
ELIF VA00 EQ 22
(the sky is not blue and the grass is not green)
ENDI
|
Which one you use depends entirely on the situation: if you're only combining two conditions, the first method is certainly more straightforward at a glance. But if you're combining more than two conditions (perhaps you want to check if the sky is blue, if the grass is green, and if there's a mild breeze) that method will double in complexity with each condition added, which can get messy very quickly. The second method has an advantage in that situation, because the final condition retains the same structure no matter how many conditions are involved.
It also makes it easier to use the same action for different conditions, because you can do fun stuff like this:
DOIF VA00 EQ 11
(the sky is blue and the grass is green)
ELIF VA00 EQ 12 OR VA00 EQ 22
(the sky is blue but the grass is not green, OR the sky is not blue and the grass is not green)
ELIF VA00 EQ 21
(the sky is not blue but the grass is green)
ENDI
|
There's a lot that could be said about conditions and how to use them, but any method depends on what works best for your agent and what makes the most sense to you. I think that's why I find conditions one of the most fun and interesting aspects of coding.
- Ghosthande