We all take things for granted and I recently found renewed appreciation for the VFP compiler catching simple things. Over the last week I have been working on and off to track down an indexing issue brought to my attention by one of White Light Computing’s sub-contractors. It is an issue between VFP and FoxPro for DOS.
One of my test programs runs in FoxPro 2.6a DOS and had the following code:
llSeek1 = SEEK( “CRANE “, “test”, “lo_locn” )
llFound1 = FOUND()
llEOF1 = EOF()
I posted the code for a code review and it was revealed to me something I know: FoxPro 2.6a does not support the third parameter for the SEEK() function. FoxPro 2.6a for DOS and FoxPro 2.6a for Windows happily accept the line of code and ignore the extra parameters. I guess the FoxPro compiler figures this is a mistake on your part and is doing you a favor by ignoring the problem. In my case it was bad because I did not have the proper index tag selected and I was getting misleading results.
In VFP, the compiler catches extra parameters. If you add a fourth parameter to the SEEK() function VFP provides you some responsible feedback.
Compiling d:\devvfp9apps\junk\program1.prg
llSeek1 = SEEK( “CRANE “, “test”, “lo_locn”, “more?” )
Error in line 23: Too many arguments.
Compiler rules being tighten does cause pain initially, but in reality this is one of the best things the Fox Team did for us over the many versions released. I work in several versions of FoxPro and VFP these days, and understand the tweaks on the syntax is something I get burned on once and awhile. I really appreciate when the compiler saves my bacon.
One of the other things I commonly see with code I am working on is the ENDIF comments. For instance, sample code:
IF llCondition
llQueryOK = .T.
ELSE
llQueryOK = .F.
ENDIF llCondition
Initially looking a the ENDIF one might think this is invalid syntax (ok, maybe I was the only one {g}) and the developer forgot to put in the && inline comment. In reality, FoxPro knows there is no valid syntax after the ENDIF so the rest of the line is completely ignored at compile time. This happens in all versions of FoxPro.
We have been taking on quite a few projects over the last year and my preference is to recompile to VFP 9 so we support fewer versions of VFP compilers and runtimes, and I want to take advantage of the stability of VFP 9. The most common compiler error I see is the lack of commas separating variable declarations. This one drives me crazy. It is easy to fix for sure and VFP 9 is really good about pointing out the problem.
I guess the FoxPro compiler figures this is a mistake on your part and is doing you a favor by ignoring the problem.
This is a good example of why I’ve stopped, and recommend against, VFP programmers trying too hard to protect programmers from passing bad or incomplete parameters. It’s doing a disservice to all. Better to use an ASSERT when an unexpected type is passed or not enough parameters are passed.
BTW, I had a similar experience recently with 9. Some native function…but I don’t recall now what it was. Just was surprised. If I recall it will post.
Initially looking a the ENDIF one might think this is invalid syntax …. FoxPro knows there is no valid syntax after the ENDIF so the rest of the line is completely ignored …
Similarly, VFP accepts the keyword THEN when placed after IF condition. For example:
IF x = y THEN
? “OK”
ENDIF
Not only does this not throw an error, but Intellisense recognises THEN as a keyword and renders it in blue upper case.
Handy for ex-Basic folk, perhaps?