mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (02/04/89)
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.BITNETecphssrw@afws.csun.edu (Stephen Walton) (02/07/89)
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 :-) .
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (02/11/89)
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
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (02/12/89)
: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. I agree. But Lint does not, never has, and never will force the kind of structure a beginner needs. Oh, I admit it checks a *few* possible structural problems, but so little compared to the myrid possibilitiies that I think anything one might gain from using lint for that purpose they would loose even more being fooled by what it doesn't catch, as well as not learn as much as they might in the art of debugging. -Matt
gksmith@watcgl.waterloo.edu (Gary Smith) (07/05/89)
I am looking for a good (I'll settle for anything right now) lint program . I am currently using the Aztec v3.6a C compiler. Is there an Amiga ftp site at which I could pick up a copy? I saw some sort of lint program in a Fish disk listing but I urgently need this debugging tool so I would rather not send away for it. Thanks for any info. Gary.
ecphssrw@roger.csun.edu (Stephen Walton) (07/07/89)
In article <10558@watcgl.waterloo.edu>, gksmith@watcgl (Gary Smith) writes: > >I am looking for a good (I'll settle for anything right now) lint program. The commercial product Amiga Lint is available for $99 direct from Gimpel Software in Maryland or at your local dealer for, I'm sure, a significant discount. The latest version, V3.03, works very well. (IMHO, the combo of Aztec 3.6a plus Gimpel Lint is nearly as good as Lattice V5.02.) >Is there an Amiga ftp site at which I could pick up a copy? Think about how much work goes into a really good Lint, and you'll realize that $99 for one is a bargain. No one is going to write one and give it away. >I saw some sort of lint program in a Fish disk listing What you saw was a set of support files for using Version 2.nn of Gimpel Lint, written by William Althoff. An updated and corrected version of these is included with V3.03.