Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ucsd!orion.cf.uci.edu!uci-ics!venera.isi.edu!aero!sm.unisys.com!csun!solaria!ecphssrw@afws.csun.edu
From: ecphssrw@afws.csun.edu (Stephen Walton)
Newsgroups: comp.sys.amiga.tech
Subject: Re: lint...
Message-ID: <469@solaria.csun.edu>
Date: 6 Feb 89 21:46:29 GMT
References: <8902040530.AA29151@postgres.Berkeley.EDU> <19927@agate.BERKELEY.EDU>
Sender: ecphssrw@solaria.csun.edu
Reply-To: ecphssrw@afws.csun.edu (Stephen Walton)
Organization: California State Univ., Northridge
Lines: 45
In-reply-to: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer)

In article <19927@agate.BERKELEY.EDU>, mwm@eris (Mike (I'll think of
something yet) Meyer) writes a great deal of sense about Lint, C, and
programming practices.  I only have one or two comments to add.
>In article <8902040530.AA29151@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
>
><I'm not sure about that - how much does lint catch that isn't already
><caught by Lattice when you put it in picky mode?

If Amazing Computing had ever published the Gimpel Lint review I sent them
a year ago, you'd know the answer is, "Quite a bit."  It checks that your
printf/scanf format strings match the number and type of arguments.  It has
an optional warning about funny indentation; i.e.
   if (a)
      if (b)
         c;
   else
         d;

will get you the warning that the else is to the left of its
associated if.  Unlike a compiler, it works globally, so it can tell
you, for instance, if you were sloppy and have two different
prototypes for the same function. Usw.

>Those who use object-oriented languages do so because they feel
>they will be more productive with them (whether or not they are is
>another argument).

I don't use an OOL, but I thought the main reason for them, as well as
for good and consistent coding style, comments, Lint'ing, etc. was to
make it easier for someone else to maintain your code.  For most stuff
posted to comp.sources.amiga, that is not relevant, but it sure is in
a large organization where much code outlives the person who wrote it.

><	Another common misconception is that forcing structure and/or
><checking structure will make a better programmer out of the beginner.  It
><doesn't.

I think I'd disagree here (this is Matt's comment, but Mike agreed
with it).  Good program structure is to programming what a good prose
style is to writing:  the set of rules which helps the beginner avoid
common errors.  Once you are no longer a beginner, you will be able to
judge for yourself where those rules can safely be broken.

Some thoughts from an astronomer who has seen more than his share of
badly written code, mainly Fortran :-) .