>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.]