Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site bunkerb.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!ittatc!bunkerb!garys
From: garys@bunkerb.UUCP (Gary M. Samuelson)
Newsgroups: net.lang.c
Subject: Re: questions from using lint
Message-ID: <633@bunkerb.UUCP>
Date: Fri, 2-May-86 17:26:52 EDT
Article-I.D.: bunkerb.633
Posted: Fri May  2 17:26:52 1986
Date-Received: Sun, 4-May-86 04:48:54 EDT
References: <7097@cca.UUCP> <759@ccird2.UUCP> <475@snow.warwick.UUCP>
Reply-To: garys@bunkerb.UUCP (Gary M. Samuelson)
Organization: Bunker Ramo, Trumbull Ct
Lines: 70
Summary: 

In article <475@snow.warwick.UUCP> kay@warwick.UUCP (Kay Dekker) writes:
>In article <7097@cca.UUCP> dewitt@cca.UUCP (Mark DeWitt) writes:
>>After three years of C programming I'm just starting to use lint, so
>>please no negative reinforcement by flaming about how stupid my questions
>>are, lest I give up on it entirely :-).

>Mark, I'm not flaming you, but I *am* worried!...

And well you should be.

>People, what are *we* doing wrong when somebody can spend 3 years programming
>in a particular language and only then start using one of the most important
>development tools for it?

Good question.  I offer the following opinion:  generally, even though
most companies (and schools, for that matter) give lip service to
"proper" development techniques, in reality they reward those who
write sloppy, un-commented, ill-planned or un-planned code.

Did you not read the discussion about the teaching of programming?
Some, thank God, do pay some attention to issues such as style, but
most still look only at the output.  And many companies are worse
than schools.  Productivity is measured in lines of code -- which
means that if you are actually trying to *design* before writing
code, you aren't being productive.  Some places don't require
specifications; some do, supposedly, but any pile of paper with
the word "specification" on the top sheet will apparently do.
Fewer still understand the difference between a requirement (storing
data) and design (let's use a hard disk).

Some people -- in senior management positions, where they ought
to know better -- actually believe that "we can't afford" to do
things like impose coding standards, much less have design reviews
or even code reviews.  It is practically a proverb that "there's
never time to do it right, but there's always time to do it over."
Such short-sightedness -- the belief that having a program which does
*anything* resembling what the user wants is better than waiting
another week -- results in all sorts of trash being shipped Friday
only to be junked Monday.

Of course, part of the problem is that a lot of C programmers in
particular learned C from the Unix (tm) source.  I just picked 'rm.c',
more or less at random, and found exactly one comment:

	all files following a null option are considered file names

That's it.  It isn't even obvious that 'rm.c' removes files (I
suppose that one would eventually find that there is an 'unlink'
call in there somewhere, and figure it out).

>It's got to the point when if I'm doing program surgery and someone comes up
>saying that their program "doesn't work", if they haven't brought a
>line-numbered listing of the source AND a lint output, I don't really want
>to start looking for the problems.
>							Kay.

Good for you!  That is the type of attitude required.  In many cases,
I would go even further and require that the line-numbered listing be
part of a cross-reference.

Also, when someone says, "This program doesn't work," it is often
revealing to ask, "what's it supposed to do?"  It is amazing --
and frustrating -- how often the person can give no clear answer.

Gary Samuelson

>"I AM; YOU ARE; HELLO: all else is poetry"
>			... mcvax!ukc!warwick!kay

At last! someone who appreciates my poetry! :-)