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.
--
https://mail.python.org/mailman/listinfo/python-list
