Fix All Warnings And Errors: what is the history of this code quality tactic?

Question

Fix all warnings and errors. Do not tolerate any error messages in your application logs but fix them as soon as they appear.

I first read a similar passage perhaps in 1999. Since then I have encountered the phrase "fix all warnings and errors" throughout the literature on code and testing.

Who said this first? And since then, who (if anyone) has provided either anecdotal or (prefereably) empirical evidence that "zero warnings and errors" in a software application is beneficial?

FYI: OP is "historian of software and particularly of software testing".

Answer 1

Steve McConnell writes in Code Complete (1993):

p69:

Eliminate the causes of all compiler errors and warnings. Pay attention to what the compiler tells you about your code. A lot of warnings often indicates low-quality code, and you should try to understand each warning you get. In practice, warnings you've seen again and again have one of two possible effects: You ignore them and they camouflage other, more important warnings, or they become annoying like Chinese water torture.

p664:

Set your compiler's warning level to the highest, pickiest level possible and fix the code so that it doesn't produce any warnings. It's sloppy to ignore compiler errors. It's even sloppier to turn off the warnings so that you can't even see them.

Answer 2

I probably first encountered this in the perl community, where the advice to use warnings "all"; and use strict; is so common. My guess is that I first read this in "effective perl programming" by Randal Schwartz - looks like it is on page 146. That book was published in 1998.

I have had a lot of success with that approach for pointed and small programs, and a few large but batch-mode ("IT Shop Processing") applications. A few things I would note:

1) This makes you very dependent on your code libraries. If you use libraries that throw off warnings and errors, you are hoser-ed. (I can use that term, it's basically my last name.)

2) It also makes you very dependent on your infrastructure. If you want to see no warnings and errors in your server logs, you'll have to be building a rock-solid app on a rock-solid tech stack. This would never work, for example, on early versions of Ruby On Rails -- the underlying software was simply not solid enough.

3) Conclusion: This might work fine on your little EDI-To-EDI conversion script. However, the wider you spread it, the thinner it gets - try no errors or warnings in your fortune 500 data center and see how far that gets you.

That said, while you might never get there, nearly all the clients I've worked with could benefit from moving in that direction. In fact, most of them have so many errors and warnings they routinely ignore that entire categories of software exist to monitor logs and tell you when NO REALLY, THIS ONE you should pay attention to. Some of them use AI or machine learning.

In most cases, it's possible to reduce the number of spurious and silly warnings we can ignore by a factor of ten or more.

And that, my friends, is a challenge worth accepting.

Answer 3

I totally agree with Neils, and I'd like to address the question of whether or not this post belongs on this Testing site.

Good testing starts long before any code is written, especially when it comes to the job of preventing error and simplifying future testing.

Some basic testing principle apply regarless of the language used or application developed, One of these principles is this:

Complexity makes testing more difficult.

A tester faced with error messages is trying to deal with extra, unnecessary complexity—things to look at that have no relevance for the testing job. Get rid of them.

One potential counterargument: Failure to clean up error messages is often a sign that the developer coded in haste. Coding in haste is a recipe for making coding errors, so a lot of uncleared warning messages may be a clue for the testers, suggesting potential error-prone code.

Errors Book

Answer 4

An early tool which generated warnings, with the intention to have them fixed by the programmer as if they were errors, was Lint.

Stephen Johnson. Lint, a C program checker. Computer Science Technical Report 65, Bell Laboratories, December 1977.

Reference shamelessly copied from: https://en.wikipedia.org/wiki/Lint_(software)

Note that the mentioned article does not explicitly say "fix all warnings". However, it suggests that it is desirable to achieve a clean run (no warnings produced) by providing a way to remove erroneous warnings (caused by bugs or shortcomings of Lint) to achieve the goal of a clean run.

I am, however, not aware if there were earlier tools with a similar intention.

Answer 5

If anything, it was the reverse of this -- the culture started letting errors and warnings stay in, more and more.

Back in punch card days, access to the punch card machines to read your deck of cards -- program -- was limited, often very expensive, and the deck often had to go through "verifiers," people who looked it over for errors. Even with a lightly loaded system, it could take an hour or more to run a deck, find an error, fix it, and resubmit the deck.

So programmers learned to catch the errors by eye, and never even submit anything that would cause an error.

When I learned to program in the early 1980s, and started work in 1985, punch card days were just about over (I punched and ran one deck -- ever -- as part of the training of student staff for the Bryn Mawr computer center.)

However, mid-career programmers at that time came from that background, and everyone treated warnings with real seriousness -- you simply didn't leave them in, never mind errors. It was a bit of a shock to encounter warnings that did have to be left in -- and you damn well knew, when you did, why you couldn't fix them, and how and why they wouldn't cause problems.

I mean, why have warnings if they don't mean something? And they very often do: WARNING: DO THIS CARELESS DECLARATION AND YOU WILL RANDOMLY OVERWRITE IMPORTANT BITS OF MEMORY. Though IIRC, Visual C++ in the late 1990s started spewing a lot of useless and intractable warnings. I have a vague memory that constructs that generated Visual C++ warnings were considered OK if the Gnu compiler would accept them without warnings.

I still feel that way about warnings. I prefer to test my code incrementally as I go in any case, by pasting it into an interpreter or a test file to compile -- so if a warning pops up, it's usually easy enough to get rid of, then and there.

I believe Henry Ledgard's Programming Proverbs, or his later book, Fortran with Style: Programming Proverbs, recommends knowing your programming language well enough so that you never generate warnings; he had been a punch card programmer. These days, of course, the challenge is tracking which language you're currently using -- wait, is this the one with "else:" or "else {...}"?

Answer 6

I wonder if it is relevant who said it first. I expect it historically to be more in line with many different teams running into similar issues with warnings and errors before they wrote it down as a rule in a book. Who said it first will probably be a lot of separate people in different programming teams around the globe. I think this is a logical rule each individual team will eventually come-up with.

The reason to fix all warnings and errors is because if you don't make a habit out of fixing them, you will be flooded with them. Probably causing you to ignore warnings and errors that might be relevant. Eventually you get a production issue because someone ignored them for to long.

Also during coding they flood your output making it harder to read or find the output you do need to read. Keeping one or two warnings or errors might not be a problem in the beginning, but it could set a standard to not fix them anymore at all. Leading to problems down the road.

I have seen an error logging system which recorded over 200k errors in a week sometimes. When we had an issue that needed debugging it was very frustrating for the developers to go through all of them.

Same goes for warnings. Most warnings now-a-days are about deprecated functionality. If you don't remove them as soon as possible you cannot upgrade libraries. Possible leading to security issues and so on. If you would never fix the warnings, because they are optional, then you probably miss the important warnings.

Fixing one warning or an error is often easy, but fixing thousands will be a major effort. This might never get priority, because it is not fun to fix, nor has good business value. Possible making the mess even bigger over time. Keeping it under control seems like a sane advice :)

Clean code:

This might also be another good time to advocate clean code. Clean code is code for humans, not computers. Robert Martin suggests that code should be optimised for readability, so that other humans can work in it easier. This has a lot of other advantages.

The same goes for warnings and errors. They don't confuse the computers, those will do their job just fine with errors and warnings, just like they will execute messy code just fine. The thing is warnings and errors confuse humans. They will wonder why is it here? Should I do something with it? Who left it here? Is it here for reason? Can I also ignore it? Should I?

Don't let other developers do double-takes. Make it clear what the intent is and fix warnings and errors to prevent confusion and unneeded questions.

Answer 7

One part of the Ruby on Rails history over the last ten years is that frequently changes are marked with deprecation warning messages in one version before backward compatibility is removed altogether in the next version. So experienced folks in this community have learn to ignore those warnings at their peril.

Over 30 years my personal experience has been that they grew over time and eventually get to a point where there is too much noise and too little signal and you don't know what warnings to be concerned about - especially for newer folks joining the team.

Answer 8

Practices of an Agile Developer, Subramaniam & Hunt, 2006. Page 137 has this...

Just because your compiler treats warnings lightly doesn't mean you should.

Treat warnings as errors. Checking in code with warnings is just as bad as checking in code with errors or code that fails its tests. No checked-in code should produce any warnings from the build tools.

Searching that phrase on Google Scholar turns up a couple of papers discussing static analysis tools and the merits of warning messages. Example; "A few billion lines of code later"

Answer 9

Since you asked for anecdotal, this is about as anecdotal as it gets. This is a very opinion based question.

First:

Fix all warnings and errors. Do not tolerate any error messages

Can be impractical, depending on the size/scope of an application. Some applications have many, many pieces, and you/your team are not in control of all of them. They will throw errors/warnings, and there's nothing you can do about it.

However, of the things you can control:

but fix them as soon as they appear.

I emphasize "as soon as they appear" because this is the best and easiest time to fix it. Developers will have the code fresh in their minds, and a fix will be quick and easy.

More important, have you ever heard a developer say, "I'm going to fix that later"? I have. Then code reviews come up, and they either didn't fix it, or put a TODO and it's still not fixed. This doesn't happen every time, of course, but it's very frequent.

After seeing this a few times, "I'll fix it later" was removed from my vocabulary, and I don't put my stamp of approval on code reviews with fixitlaters™.

So here's the point: One should strive to fix all warnings and errors as soon as they appear because if they're not fixed now, they won't be fixed. There are future repercussions, even if it might seem pointless today.

Someone will inherit the code. They won't know the full history, and may assume it's a legitimate problem. Said person spends time chasing down a bug that doesn't exist because, let's face it, you were just too lazy to fix the benign warning/error. Plus, they fill up server logs needlessly, making real issues harder to find.