Lint Should Never Have Been Separated Out

You'll notice a consistent theme running through many of the above problems: lint detects them and
warns you. It takes discipline to ensure that code is kept lint clean, and it would save much trouble if
the lint warnings were automatically generated by the compiler.

Back in the early days of C on UNIX, an explicit decision was made to extract full semantic checking
from the compiler. This error checking was instead done by a stand-alone program known as "lint".
By omitting comprehensive error-checking, the compiler could be made smaller, faster, and simpler.
After all, programmers can always be trusted to say what they mean, and mean what they say, right?
Wrong!

Handy Heuristic

Lint Early, Lint Often

Lint is your software conscience. It tells you when you are doing bad things. Always use
lint. Listen to your conscience.

Separating lint out from the compiler as an independent program was a big mistake that people are
only now coming to terms with. It's true that it made the compiler smaller and more focused, but it
was at the grievous cost of allowing bugs and dubious code idioms to lurk unnoticed. Many, perhaps
most, programmers do not use lint by default after each and every compilation. It's a poor trade-off to
have buggy code compiled fast. Much of lint's checking is now starting to appear in compilers again.

However, there is one thing that lint commonly does that most C compiler implementations currently
do not; namely, check for consistency of function use across multiple files. Many people regard this as
a deficiency of compiler implementation, rather than a justifi-cation for a freestanding lint program.
All Ada compilers do this multifile consistency checking; it is the trend in C++ translators, and
perhaps eventually will be usual in C, too.

The SunOS Lint Party

The SunOS development team is justly proud of our lint-clean kernel. We'd paid a lot of
attention to getting the 4.x kernel to pass through lint with no errors, and we kept it that
way. When we changed our source base from BSD UNIX to SVR4 in 1991, we inherited a
new kernel whose lint status was unknown. We decided to lint the SVR4 kernel.

This activity took place over several weeks and was known as the "lint party." It yielded
about 12,000 unique lint warnings, each of which had to be investigated and corrected
manually. By the end, changes had been made to about 750 source files, and the task had
become known as "the lint merge from hell". Most of the lint messages just needed an