Re: marking mystery code (Robert Dewar)
13 Feb 1996 18:05:57 -0500

          From comp.compilers

Related articles
Re: Possible to write compiler to Java VM? (1996-01-29)
Re: Possible to write compiler to Java VM? (1996-02-09)
Re: Possible to write compiler to Java VM? (1996-02-12)
Re: marking mystery code (1996-02-13)
Re: marking mystery code (Ted Dennison) (1996-02-14)
Re: marking mystery code (1996-02-14)
Re: marking mystery code (1996-02-16)
Re: marking mystery code (1996-02-16)
Re: marking mystery code (Mitchell Perilstein) (1996-02-16)
Re: marking mystery code (Toon Moene) (1996-02-16)
[4 later articles]
| List of all articles for this month |

From: (Robert Dewar)
Date: 13 Feb 1996 18:05:57 -0500
Organization: Courant Institute of Mathematical Sciences
References: 96-01-116 96-02-059 96-02-108
Keywords: Ada, C

Gary says

"Incidentally, I saw similar comments and code obfuscations when
maintaining Fortran IV code 20 years ago. It is depressing that the
FSF sponsored code products haven't been designed, implemented, and
maintained at a higher level of professionalism than what was common
in 1976."

Gary, are you speaking from personal experiences with the FSF sources,
which many people have found easy to work with, or are you borrowing
second or third hand comments without this personal experience?

Incidentally, the practice of marking suspicious code seems a good one
to me. If code is being read by more than its author (often sadly not
the case), then a reader will often wonder what something means, and
not necessarily be able to tell if it is a bug, or if it needs more
documentation, or perhaps some invariant that is assumed is not 100%
right etc.

In GNAT we use ??? for this purpose, and there are quite a few ???
around the place. I suspect that nearly all large projects have
numerous instances of code which merits the ??? mark, but they don't
get marked.

In GNAT, each ??? is a potential bug. It could be an out-and-out bug,
or just an obscure case not covered, or simply a lack of
documentation, or a case where the code is not wrong, but can be
cleaned up. Of course the idea is that ??? comments eventually
disappear -- they are essentially low priority bugs, which have not
showed up in any test program, and perhaps could NOT result in a
failure, but nevertheless should be fixed.

I find that the systematic attempt to clean up such spots in code,
even if not driven by bug reports, is a way of aiming at higher
quality, and is a practice that much code in the field that I see
could benefit from.

Post a followup to this message

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