Now THAT code is SCARY...:o) How long did it take to determine what each condition actually was testing for? I agree, I would much rather try to interpret a complicated IIF statement then the IF...ENDIF code below! I agree that IIF should be used for fairly uncomplicated conditions and regardless, all conditional statements should be well documentated!
:o)
Tracy

>Hi Tracy,
>
>Not to disagree with you (bg), but ...
>
>I personally use IIF() wherever a -single- condition exists, and use proper code indention to show what's supposed to happen for each value of the condition. I've found that if properly indented, most developers can grasp each side of the condition pretty easily. I have done some nested IIF() statements before -- but I don't like to, for much the same reasons that you state.
>
>The reason I even jumped into this discussion, though, is to caution those reading this thread against going too far in the other direction. Witness: some code I just looked at last Friday from the original provider of a (supposedly) professional pension fund management software package we're working with:
>
>

>IF Condition1
>  IF Condition2
>    IF Condition3
>      IF Condition4
>        IF Condition5
>          IF Condition6
>            IF Condition7
>              WorkValue = m.GlobalValue
>            ENDIF
>          ENDIF
>        ENDIF
>      ENDIF
>    ENDIF
>  ENDIF
>ENDIF
>

>
>This was exactly as written -- no comments, no header, NOTHING else to tell anyone what's happening here.
>
>IMHO, this approach is *just as confusing* as nested IIF() statements and one heck of a lot more difficult to work with. Try, for instance, placing some other code in this structure for one of the middle conditions without doing some serious formatting changes (shudder).
>
>Just my .02 --
>
>
>>This discussion reminds me of a personal experience I had. I tended to code using IIF instead of IF/ENDIF when possible under the assumption that 1) it will run faster and 2) I can use the IIF statement easy in a report. I always use documentation to explain the conditions above the statement.
>>
>>However, when other programmers were making mods to one of the apps I developed, they came across my IIF statements and rewrote them ALL using IF/ENDIF because EVEN THOUGH THEY WORKED FLAWLESSLY, the other programmers could not understand the conditions without breaking it down into IF/ENDIF statements. They were afraid to modify the statement in anyway if the condition needed to change for whatever reason because they feared it would no longer 'work.'
>>
>>I now code whenever possible using IF/ENDIF instead of IIF simply because sometimes it is better to make the code more easily understood by other programmers than to make it a little faster.
>>
>>I guess that's teamwork :o)
>>Tracy
>>
>>>Sergey;
>>>
>>>The greatest “joy” of all working with conditional statements is imbedded IIF’s! That is multiple IIF statements within each other. Not a good thought for a Friday. :)
>>>
>>>Tom
>>>
>>>>>Sergey;
>>>>>
>>>>>I think all code should be contained on one line - it runs faster. My goal is to write a complete application on one row. Think of the speed! :)
>>>>
>>>>At some point, under influence of the C book I read at that time, I wrote code like that

llOk = Func1() And func(2) And (Func3) ... and so on

Not very readable but compact. :)
>>>>
>>>>>In real life I will normally use structured code for readability and sometimes IIF statements when needed. Some IIF statements can be complex to understand.
>>>>
>>>>The same here. If I've a choice between IIF() and IF I would use IIF() only if condition is simple and there could be multiple separate squential statements with IIF()'s. In this case code would be more readable with IIF() because of it compactness.