🚀 go-pugleaf

:programmers. It's relatively cheap and works pretty damn well; I think
:every commercial developer working in C should get and use a copy. 
:
: ComicSetter lints cleanly ... does YOUR program? 
: 
:cks@ziebmef.UUCP	     or	.....!utgpu!{,ontmoh!,ncrcan!brambo!}cks

	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.

	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.  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.

	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.

					-Matt