Re: Compiler Books? Parsers?

"Mark Sayers" <>
7 Jan 2004 00:59:13 -0500

          From comp.compilers

Related articles
[9 earlier articles]
Re: Compiler Books? Parsers? (Nick Roberts) (2003-12-08)
Re: Compiler Books? Parsers? (Marco van de Voort) (2003-12-20)
Re: Compiler Books? Parsers? (Chris F Clark) (2003-12-21)
Re: Compiler Books? Parsers? (Carl Cerecke) (2003-12-23)
Re: Compiler Books? Parsers? (Chris F Clark) (2003-12-27)
Re: Compiler Books? Parsers? (Oliver Zeigermann) (2004-01-02)
Re: Compiler Books? Parsers? (Mark Sayers) (2004-01-07)
Re: Compiler Books? Parsers? (Jeff Kenton) (2004-01-09)
Re: Compiler Books? Parsers? (Oliver Zeigermann) (2004-01-22)
| List of all articles for this month |

From: "Mark Sayers" <>
Newsgroups: comp.compilers
Date: 7 Jan 2004 00:59:13 -0500
Organization: Compilers Central
References: 03-10-113 03-10-145 03-11-010 03-11-083 03-12-017 03-12-116 03-12-125 03-12-132
Keywords: errors
Posted-Date: 07 Jan 2004 00:59:13 EST

I thought I would throw my 2 cents in too.....

From my experience of the professional world I would agree most of the
common errors that occur are due to fragments of code being copied and
pasted from one location to another and not altered correctly.

In many cases its quite possible to do this within a function such
that the variables are indeed valid, however not amended in such a way
they produce the desired effect. This isnt something which I believe
can be remedied by a better (or worse) compiler or my experience with
a given programming language. It is simply a matter of taking care
when making changes to code and testing that something peforms the
task it is intended to.

At the end of the day a computer program can be correct in terms of
lexical anaylsis and syntax but a compiler cant be expected to know
what the programmer wanted to happen and amend their code to do this
when they have made a mistake of this type. Its a matter of human
error not compiler error or design.

It is possible and is more the norm that typos can be detected however
variables with similar names can be problematic with regards to human
error, at the end of the day checking the code visually is correct and
testing it does what it says on the packet is the only really sensible
approach to produce reliable and robust software.

My personal believe if that too great a percentage of time is spend
coding and not enough on the design of the software to begin with to
produce easily maintainable code that is readable. Often some people
seem to go for the approach of slap it together and cross your fingers
or a design which is over complex or to try and incorpoprate means of
efficency in the code which can be better facilitated with compiler
optimisations instead of by hand.

At the end of the day a readable and reliable piece of code which is
then optimised for peformance or speed by the compiler or other tools
is a more valuable comodity than one which is pulling all kinds of
tricks and confusing and baffling to not only other people trying to
maintain the code but often to the programmer themselves when trying
to remedy problems at a later date.

It is fair comment to say that many newbie programmers do make common
mistakes due to their lack of understanding of what they are trying to
achieve and how to actually achieve it, however the bigger picture as
to how these people are taught to write code when they get into the
work place is more of an issue.

Its all good and proper to make mistakes when your learning something
and developing your skills, but in the commercial world making
mistakes costs money and the time spend checking things and
determining a problem earlier rather than later is a more effective
use of resource (though often project managers do not seem to always
believe it at the time).


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.