>>>I agree with Bret and George. Also, to make one small addition to the readibility issue, CASE structures are alot easier to read and debug than nested IIF() statements. I spent half a day one time changing IIF() statements, some nested 5 to 6 levels, to CASE structures in a program I inherited. The readibility of the code is a million times better and there was no visible difference in performance.
>>
>>Agree 100%. If there's any chance your code will ever become legacy code for someone else, then it's better to go this way. I've been on the other side of that coin, and inheriting messy & difficult IIFs isn't much fun...
>
>Agree too. It will highly depend on expansion or not.
>If only do simple
Assignment on Variable,
>I even want to try any .NOT. case.
>
>Such as a Button action as On/Off Switch!!
>* btnSwitchForm.Click
>ThisFormset.fOTherForm.visible = !ThisFormset.fOTherForm.visible
>
>because Not gate calculation is 3-5 times faster than comparasion nor
>.AND. .OR. gate in thm. Instead of:
>ThisFormset.fOTherForm.visible = iif(ThisFormset.fOTherForm.visible, .f., .t.)
>
>But in some case, In order to
further expand, I even use DO..CASE instead of IF..ELSE..ENDIF
>For All the KeyPress Event procedure.
>Even only I take one nKeyCode, I use Do Case as very easy on expand as
>need to further concern the other additional functions!
>
>* Form.KeyPress
>DO CASE
>CASE nKeyCode = -1 && F2
> ThisForm.cmdGroup.CmdAddNew.Click
>
>CASE nKeyCode = -7 && F8
> ThisForm.cmdGroup.CmdDelete.Click
>ENDCASE
>
>In case I need a update, search, or other additional, maintain will be easy!
Hi Justok,
This is not a reply to you indeed but to thread. Seeing the names replied to this thread it seems my style is the wrong one but I'll tell it honestly. If..endif and do case..endcase are structural elements. There are times that you could never replace them with iif(). iif() is a built-in function and also there are times it can't be replaced with if..endif, do case..endcase w/o so much coding, adding unnecessary function/proc/method whatever, having performance penalty (ie: try to do an SQL that would sum a value from one field into two new fields depending on a type -income,outcome- field). Historically iif() was introduced to FP (I should say including Foxbase) later and I was very pleased of it. Regarding to original question, it's absolutely faster, can be used anywhere that you need a value based on a comparison (ie: try to set dynamicbackcolor with if...endif - if ever it's intelligent to do) etc etc. When it comes to readability, then hmmm, it's up to you, it's coding habit. In fact I rarely use commenting too (don't blame me - I can easily follow my noncommented, many iif() code while it's hard to me to follow someone else's well commented, many if..endif, do case...endcase code - my penalty is when posting to UT I begin to comment). Also I really love the NVL() function and prefer it to if..endif or even iif(oldval(), bla bla bla, bla bla bla). That is my way. It's my coding technique and my way that I even change to iif() when touch my old fox code - provided version supports (I wasn't good with iif() those days). Iif() doesn't replace do case...endcase of course. I could be doing something based on weekdays with a return value per day, I would choose do case..endcase in code but if it would be used once or subject to something like calculated controlsource then might prefer iif() way. One can be used in interactive mode while the other cannot be. I would absolutely choose iif() for simple if..endif, do case..endcase structures whenever possible. From debugging point, I could debug the iif() from the command window in any FP version then. Well, it's impossible to say this one or that one is better, like I never could decided if I should do coding visually or nonvisually also. These are all programming techniques that cannot be restricted to a standart (of course I would obey UT decision if ever a standart is constituted). And final word, FP at all times is so fast that we can't see a difference using one or other.
All have a great day.
Cetin
