LINT as documentation

[Rex Ballard]

This is just one more argument for lint.

True, lint often burps over "trivial" little problems like
passing a *int to a function that expects *char, among others,
but there are some real good reasons for using lint.

Frequently, after working on a project for several months and
coming up with a working system, it gets passed to someone else.
That someone else then has to make a small enhancement that affects
only one module out of 100.  This second person might not understand
that this *int is not really a pointer to integers, but is in fact
a pointer to some more complex type.  By putting the casts, VARARGS,
NOSTRICTS, et al, the new guy at least gets a warning that something
is not what it appears to be.  This is particularly important if
I do something like us an int as a pointer to char (yuckkk!!! :-).

Now, if either he or I induce a new bug, or something that might
need explanation, lint is there finding that "1/5" of the wierdness
that might have gone wrong.

Even more important is when we switch compilers, go to cross-tools,
or use some other change in the environment.  If the thing has
been linted, casted, and cleaned up, we can ASK it to tell us
about "dubious casts", or whatever and have a better idea of why
things don't work as well.

When someone comes up with the "lint cramps my style" arguments,
I tend to get worried.  When I get handed some code that has to
be "ported" or enhanced, I run lint on it before I do anything.
If lint goes crazy, I know I will have to read ALL of the code
before I can do anything.

There are a lot of cute "tricks" you can do with C, like setting
"pointers" that are really integers.  But if you want to do this,
you should be explicit in defining "(char *)0x2300ffff".  Believe
it or not, I have actually seen code that legitimately calls
address location 0 (useful on the 8085).  This is guarenteed to
drive a programmer crazy if he tries to port this to another machine.

I also expect a programmer to run code through lint before he
gets my help.  I have spent too many hours with people who insist
the compiler is broken because they have tried to, in effect,
build an array in the operating system vector space :-).
If he really WANTS to build an array in the operating system
vector space, he should SAY SO, not just to me, but to lint.

I find it amazing that an employer would pay a programmer for
three days worth of debugging using ODT (octal debugging toy)
to test and debug code when all but one hours worth could be
found in a 2 hour session of lint/vi.

Real Programmers CAN use the "front panal", but they won't if
there is a faster easier way!

If you are programming on your own time, and don't have any plans
for releasing your code to anyone, then don't use lint.  But if
you want to "publish" your little gem, the $95 for lint on a
"PC" will easily offset the $20/hr*20 or thirty hours someone
might spend getting it to run on their "not quite compatible".
This is especially true on 68K machines where Ints can be
short and pointers can be long and (*char)i can do some really
nasty things.  Sure it's possible to use the "long int switch",
but then the program runs 150% slower.