Many of us, inculding myself, learned foxpro by debugging and enhancing applications written by someone else. And although I have a BS degree in CS, foxpro is the only language I've ever used professionally. Many of the annoyances listed in this thread I use all the time because that was the way I learned from someone else. I think a lot of you guys had a background in c where effeciency is god and iif's don't exist.
I for one learned a lot from this thread and will be changing my programming habits accordingly.
Someone should put a document together of these things, listing common annoyances and the better way to do it.
On a similar note... Since I learned programming basics in college we learned all about loops of course. So I always used "Do While !EOF()" instead of "SCAN" to move through a table and I would always forget to put in a SKIP at the end. Now that I've discovered SCAN I always use it instead.
>Here's a quote from a recent thread:
>
loColumn.DynamicFontBold = "'IIF(THIS.PARENT.gnRecNo = RECNO THIS.PARENT.RecordSource), .T., .F.)'"
>I wouldn't be starting on this if this was the only one, but I'm seeing the IIf({expL}, .T., .F.) just far too often, so I started wondering what made this become customary.
>I've even seen IIF(.T., .F., .F.) in a property (where a string containing a logical expression was expected).
>What I don't understand is why would anyone want to write
>
If DESCENDING()
> Thisform.lSaveAscending = .F.
>Else
> Thisform.lSaveAscending = .T.
>Endif
>instead of
>
Thisform.lSaveAscending =NOT DESCENDING()
>Or why is this form
>
llHasValue=iif(empty(lcValueString), .F., .T.)
>preferrable over the
>
llHasValue=not empty(lcValueString)
>Was it a readability issue, or what? I'm still thinking that
>
c=a#b
is more clear and more readable than
>
c=iif(a=b, .f., .t.)
or, worse,
>
if a=b
> c=.f.
>else
> c=.t.
>endif
>Is it just my pet peeve, or are there some recommendations about this?
Rip Ryness
International Falls, MN