>I’m sorry for going back to the IIF discussion but…It took me a while to read the posts and then I felt embarrassed because my own opinion differs in so many regards from respected members of the FoxPro community.
I found the differences rather limited to certain areas, I think this is all agreeable with the general opinion (or at least one part of the opinions) expressed here.
>
IF …ELSE … ENDIF >Several people stated that they consider it a bad coding practice to have an IF without an ELSE. I would prefer to say that
one should always think about the ELSE but I don’t believe one should always
code it.
Right - I think I also mentioned that the reason for omitting the Else should be commented if it's not that obvious.
>
>if vartype(tMan) <> “C”
> Return this.throwerror(“Bad Man”)
>else
> if vartype(tPhilosopher)<>”C”
> Return this.throwerror(“Bad Philosopher”)
Ahem... Return this.throwerror(“Philosopher wihout character”) or Return this.throwerror(“Philosopher's character not variable”)?
>I know that none of you would code like this because it disobeys the rule to keep your logical structures flat but someone new or from another language might obey the rule literally.
>
>Another example: suppose you have a program for making soup one might have look like:
>
>if not this.lEnoughSalt
> this.AddSalt()
>endif
>if not this.lEnoughPepper
> this.AddPepper()
>endif
>
>with many many if conditions. I believe adding ELSE decreases the readability of the function by almost doubling the length of the code -- assuming you add a comment in the else. If you don't have a comment any maintenance programmer is going to assume that you just forgot to code the else and will spend an hour trying to deduce what ought to be there!
I think the soup case is one of the obvious ones where Else is not needed; someone may know the name of the pattern. It's a checklist, and you code the items in the list one by one, doing something only when needed - obviously doing nothing when not needed.
>There are couple reasons why I think people use the if else
>a) in FoxPro the assignment operator (=) is the same as the equality operator (=) this makes expressions like
>c=b=a hard to read even though they are sompletely valid.
This can be written as c= (b=a). That would make it clear and still an one-liner.
>b) The IF construction follows the english language better.
COBOL is the best language in that respect :)
>d) if else can be used to make an OR
>
>llIsGeologist = .f.
>if (llHasPulse AND ...)
> llIsGeologist = .t.
>endif
>if (llHasBeard AND ...)
> llIsGeologist = .t.
>endif
>
>really means
>
>llIsGeologist = (llHasBeard AND ...) OR (llHasPulse AND ...)
>
>
>this could have been coded
>
>llIsGeologist = (llHasBeard AND ...)
>llIsGeologist = llGeologist OR (llHasPulse AND ...)
>
>but the first version is probably the easiest to read.
I've read lots of code with the logic like this, and I'm still not sure which way it took me longer to understand what did the poet mean to say. Each way may have a combination of values which may skip your attention and yield an unexpected result.
>
iif>Couldn't agree with you more. Curiously I accidentally changed mz kezboard to German and can't fix it. So I apologise for any typing errors.
At times I had four keyboard layouts installed - English, Serbian Latin, Serbian Cyrillic and Hungarian. The latter is a good replacement for alcohol, until you (zou? - the latter three are all QWERTZ) get used to it. BTW, if it's getting stuck, try closing the indicator on the taskbar (or killing internat.exe from TaskManager). Swapping the keyboards with alt+shift always worked, it's the thing in the tray that sometime causes problems, in several versions of Windows.
>
DeMorgans Rule and Logical Transformations>the two expressions are logically equivalent but I find the first difficult to comment while the second requires no comment at all! I think logical transformations are worth thinking about: sometimes one gets an insight when one transforms an expression but only use the transformation if the new expression can be understood in natural speech. Pity the poor maintenance programmer!
You hit the nail on the head here. Sometimes, looking at the legacy code (even commercial framework code!) I wonder if they still learn DeMorgan's laws in CS. Though, the worst example I saw was a five-line logical expression (in, guess what, COBOL), which took me half an hour to understand, and five minutes to reduce to a two-liner (could have been an one-liner, but I've split it for readability's sake). Needless to say, the reduced version was logically equivalent to the original.
