What to use for finding as many syntax errors as possible.

MRAB python at mrabarnett.plus.com
Sun Oct 9 14:51:19 EDT 2022


On 2022-10-09 18:51, Antoon Pardon wrote:
> 
> 
> Op 9/10/2022 om 19:23 schreef Karsten Hilbert:
>> Am Sun, Oct 09, 2022 at 06:59:36PM +0200 schrieb Antoon Pardon:
>>
>>> Op 9/10/2022 om 17:49 schreef Avi Gross:
>>>> My guess is that finding 100 errors might turn out to be misleading. If you
>>>> fix just the first, many others would go away.
>>> At this moment I would prefer a tool that reported 100 errors, which would
>>> allow me to easily correct 10 real errors, over the python strategy which quits
>>> after having found one syntax error.
>> But the point is: you can't (there is no way to) be sure the
>> 9+ errors really are errors.
>>
>> Unless you further constrict what sorts of errors you are
>> looking for and what margin of error or leeway for false
>> positives you want to allow.
> 
> Look when I was at the university we had to program in Pascal and
> the compilor we used continued parsing until the end. Sure there
> were times that after a number of reported errors the number of
> false positives became so high it was useless trying to find the
> remaining true ones, but it still was more efficient to correct the
> obvious ones, than to only correct the first one.
> 
> I don't need to be sure. Even the occasional wrong correction
> is probably still more efficient than quiting after the first
> syntax error.
> 
When I did some programming in COBOL, a single omitted "." would 
completely confuse the compiler and it was best to fix that one error 
and then try again.

On the other hand, TurboPascal would also stop on the first error and 
put the cursor at the error position in the IDE, but as it compiled 
quickly, it wasn't a problem. It was no slower than it would've been if 
it had found multiple errors and you pressed a key to advance to the 
next error.


More information about the Python-list mailing list