|Re: The semicolon habit firstname.lastname@example.org (1995-05-10)|
|Re: The semicolon habit email@example.com (1995-05-11)|
|Re: The semicolon habit firstname.lastname@example.org (1995-05-15)|
|Re: The semicolon habit Paul_Long@ortel.org (1995-05-17)|
|From:||email@example.com (Daniel J. Salomon)|
|Organization:||Computer Science, University of Manitoba, Winnipeg, Canada|
|Date:||Thu, 11 May 1995 18:57:12 GMT|
> firstname.lastname@example.org (Mark Hopkins) writes:
|> First of all, syntax errors are far too trivial to be of any relevance
|> in any discussion. It might have been a concern back in the old days when
|> a programmer had to (re)submit a program to a central site, but nowadays
|> it's an entirely trivial matter to pipe an entire error listing back into a
|> program and eliminate all the errors in one fell swoop and usually doesn't
|> take much more of a minute.
The discussion was more about syntax than about syntax errors. Poor
syntax can lead to errors that persist until run time. For instance in
the C language, a programmer may become used to ending every line with
a semicolon may absentmindedly write:
while(x < 10.0);
and not notice the error. There is no syntax error here, but this statement
is almost certainly a run-time error.
Other classic examples of error prone syntax in C are:
1) Accidentally using = instead of ==
2) forgetting a "break" statement at the end of a "case" arm
3) leaving off the parentheses in a call to a parameterless function
4) forgetting a closing comment delimiter.
A more relevant question is, do you prefer the semicolonless syntax of
the C preprocessor, or the semicolons of the C language? Which one
causes more run time errors, and which is easier to read?
It is true that experienced programmers make fewer errors than novices,
but usually that is because they have made all the common errors at least
Daniel J. Salomon -- salomon@cs.UManitoba.CA
Dept. of Computer Science / University of Manitoba
Winnipeg, Manitoba, Canada R3T 2N2 / (204) 474-8687
Return to the
Search the comp.compilers archives again.