Actually CASEW instead of CASE would be traped by the compiler. Extra or missing parens as well! But not undeclared vars. So that's why i came up with the Sys() function solution, if the compiler can't catch, at least the vars would be local.

As for the code testing percentage, i would no bet too much if i were you :) This i guess would belong in the chatter.

>>When i said running all the code, i ment running ALL the code, including all branches of cases, if and else, errors etc. This is impossible. Before a release, we have a test plan in place here and i can assure you that only between 40-50% of our lines of code are executed.
>>
>>And I would bet anything this percentage is probably about right for any large application.
>
>I'm a little strapped right now or I'd be tempted to make a very large bet. I really can't believe that you think that 40%-50% of code being 'tested' is good enough, and I doubt that you actually work to that mark yourself. I have to go through every line in runtime just to find my silly typos like extra/missing parens, CASEW instead of CASE and lots of other crap like that.
>
>Maybe there should be a new thread started in Chatter (here) to ask this question.
>
>
>>
>>>I **strongly** (make that STRONGLY) disagree with your "...have to run ALL the code which we all know it is impossible".
>>>
>>>Now I would agree that one cannot run all conditions, but that is very different than running (through) all the code. And you could have a case where macros are concerned, but things can and should be done to protect against problems in those cases.
>>>
>>>I cannot think of anything that I've delivered where I didn't run ALL THE CODE! Or at the very least believe that I had run through every line of code. And this is true regardless of the language (even those that *do* inform of name or type conflicts at compile time). When I revise any program I make sure that every single line that I have changed is run.
>>>
>>>I believe that everyone else (to 99%+ anyway) does the same thing and I would be most extremely surprised if many come forward to say otherwise (the gauntlet has been thrown < s >).
>>>
>>>
>>>
>>>>I will have to disagree with "and works for most of the cases" It does not ! This option is useless since it only work with the runtime and you actually have to run ALL the code which we all know it is impossible.
>>>>
>>>>Stephane
>>>>
>>>>>Look up the help for _vfp.LanguageOptions. You already have this in VFP 7.
>>>>>
>>>>>[addition, after having read the rest of the thread: this is just a tool to catch undeclared variables, and works for most of the cases - but not at compile time, and that's bad.]