Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!pasteur!agate!eris.berkeley.edu!mwm
From: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer)
Newsgroups: comp.sys.amiga.tech
Subject: Re: lint...
Message-ID: <20210@agate.BERKELEY.EDU>
Date: 10 Feb 89 20:00:26 GMT
References: <8902040530.AA29151@postgres.Berkeley.EDU> <19927@agate.BERKELEY.EDU> <469@solaria.csun.edu>
Sender: usenet@agate.BERKELEY.EDU
Organization: Missionaria Phonibalonica
Lines: 81

In article <469@solaria.csun.edu> ecphssrw@afws.csun.edu (Stephen Walton) writes:
<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.

Nice to know someone agrees with me. Thanx.

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

I said that - not Matt.

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

Could you send me a copy of that review? I'd be interested in seeeing it.

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

Lattice warns me if I have two prototypes in scope for the same
function that are different. On the other hand, if two prototypes are
_not_ in scope, they might be for different functions (can it tell
when I've got the same name on two functions which have
non-overlapping scope?), so it should either not mention it, or have a
way of pointing out that I know what I'm doing for this case.

Finagle desire that I should ever have two prototypes for the same
function in my 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).
<
<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.

I think all of the things you mention comes under the heading of "more
productive." It makes those who have to maintain your code more
productive. And anything posted on comp.sources.amiga is _published_.
It deserves all the consideration any published document deserves -
which means making it readable, etc.

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

I don't call agreeing with that. I must have misread it. As a position
statement, I think beginners should be taught good style, and
penalized for writing unreadable code. Forcing structure on
experienced programmers won't make them better programmers. Forcing
structure on beginners is part of teaching them to write readable
code, which is part of being a good programmer. Of course, others may
wish to argue that a good programmer produces tight, bug-free code,
does it quickly, with no regard as to readability.

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

Nice analogy.

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

	<mike
--
The handbrake penetrates your thigh.			Mike Meyer
A tear of petrol is in your eye.			mwm@berkeley.edu
Quick, let's make love before we die.			ucbvax!mwm
On warm leatherette.					mwm@ucbjade.BITNET