Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!eris.berkeley.edu!mwm
From: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer)
Newsgroups: comp.sys.amiga.tech
Subject: lint...
Message-ID: <19927@agate.BERKELEY.EDU>
Date: 4 Feb 89 06:30:51 GMT
References: <8902040530.AA29151@postgres.Berkeley.EDU>
Sender: usenet@agate.BERKELEY.EDU
Organization: Missionaria Phonibalonica
Lines: 90

In article <8902040530.AA29151@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
<:programmers. It's relatively cheap and works pretty damn well; I think
<:every commercial developer working in C should get and use a copy. 

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?

<	That's kind of funny in itself though.  For example, I have never
<used lint and will never use lint ... it barfs on too many valid 
<practices and generally does not keep up with the C standard.

Matt - this is only half true. Lint doesn't keep up with C standards.
That's one of the reasons I don't see any point in using it. On the
other hand, it doesn't complain about any constructs I know of that
are valid on all architectures that C runs on - except those for which
the programmer did something that was probably a mistake. And in those
cases, there are easy ways to shut it up.

<	The main thing that I wind up saying over and over to people is
<that there is no easy solution for the experieenced programmer no matter what
<language he/she uses (so far).  That is, the programmer who writes very strict
<code and uses lint will have just as many screwy bugs in his stuff than
<the programmer who doesn't.

Once again - half true. Some screwy bugs can be caught by lint. My
favorite example is passing a struct instead of it's address (it used
to be that you couldn't pass structs, so the compiler would quietly
convert "stuctname" into it's address. Guess who converted some
non-trivial programs from that compiler to a later version.) This can
generate some very screwy bugs - and it's trivially caught by lint or
a prototyping C compiler.

<Using various code-checkers such as lint
<or switching to 'object oriented languages' as a means of ensuring that the
<programmer writes more correct code is a psychological trap ... in 
<many cases it does just the opposite without the programmer knowing it.

That's a true - but generally irrelevant - statement. I don't know
anyone who does those things "as a means of ensuring that the
programmer writes more correct code" (though I've met managers who
thought forcing there programs to do those things would do that). The
people I know who use lint do so to insure the portability of their
code. 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).

Every language has it's own set of nasty bugs it won't catch. On those
terms, ANSI C (or C+lint) is not the same langauge as K&R C, which is
not the same language as the v6 Cs (on first exposure, pcc was dubbed
"Picky C compiler" - it wouldn't even let me reference an int as if it
were a structure!). Whether you like it catching those for you is a
matter of taste - just like choosing any other language. One of the
nice things about C is you can make that choice without changing
compilers.

As you point out, the algorithmic bugs are the nastiest to catch &
fix, so those are the ones where you gain the most experience.  Since
no language catches those, it doesn't really matter how many syntactic
bugs it catches - you're still going to get the same amount of
experience - except at finding the syntactic bugs that that the other
"language" doesn't catch. So long as you don't change languages, it
doesn't matter. If you do, it's just like changing to any other
language - you've got a new class of bugs to watch out for. And like
any other language, you'll either never find them, or will pick them
up pretty quickly.

<	The ultimate errorlessness and reliability of your code depends
<solely on how well you can lay down the code.
<
<	Another common misconception is that forcing structure and/or
<checking structure will make a better programmer out of the beginner.  It
<doesn't.  It *might* be helpful removing simple-stupid (cosmetic) coding
<mistakes ... things the experienced programmer almost never make, but this
<by no means covers all the problem areas.  My guess is that, in terms of
<time, lint will catch maybe 1-10% of a beginner's mistakes and 0-3% of
<an experienced programmer's mistakes.  That's TIME, not # of mistakes.  It
<takes me a couple of seconds to find/fix stupid simple mistakes while it
<might take me hours to find/fix algorithmical mistakes.
<
<	In programming, experience counts in a big way and many shortcut
<routes simply prolong the time required to gain it.

All the above is unfortunately all to true.

	<mike
--
When logic and proportion have fallen softly dead,	Mike Meyer
And the white knight is talking backwards,		mwm@berkeley.edu
And the red queen's off her head,			ucbvax!mwm
Remember what the dormouse said.			mwm@ucbjade.BITNET