14

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

  • 2
    Is the premise of "software engineering and not testing" argument based on the belief that 'testing' is a separate discipline from 'software engineering'? – marekj Mar 16 '17 at 21:23
  • 1
    @niels-van-reijmersdal You are incorrect. Reading log messages is an essential part of the testing practice. It was the original way of testing since ENIAC and the other early mainframes did not have any output besides a log (punched into paper tape). Additionally this statement is simply false: "Fixing is about code not testing." Please provide some canonical source that supports your position here else leave the question where it is and where I strongly feel it belongs. – Noah Sussman Mar 16 '17 at 21:36
  • 1
    @NielsvanReijmersdal "Normally you do not fix anything during a test" do you have anything empirical that supports the claim that there is a "normal" (in other words, a commonly agreed upon software industry-wide default) testing methodology? Do you have any data on how many people fix code "while" testing, can you define what "while testing" even means in practical terms (concurrently with writing the test? with running the test? within a few days? as part of a programming pair?) You have no data to support any of these claims. Leave the question where it is. It belongs in testing SE. – Noah Sussman Mar 16 '17 at 21:40
  • 1
    @NielsvanReijmersdal ok so… no data to back up your claims then? I've flagged your negative comments as unhelpful since they are purely your opinion and not based in any sort of testing community standard or precedent. – Noah Sussman Mar 16 '17 at 21:48
  • 1
    Let us continue this discussion in chat. – Noah Sussman Mar 16 '17 at 21:56
2

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.

  • Thank you! I have changed this to be the accepted answer as Matt Heusser's reference was from around 1998, but this establishes the practice as early as 1993. Also IIRC, Code Complete must have been where I originally read this, back in 1999. The second passage you quote is very familiar on rereading now. – Noah Sussman Oct 24 '17 at 17:17
11

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.

  • Randal Schwartz sounds like a good bet for the original source. Thanks I will do some digging to confirm. – Noah Sussman Mar 17 '17 at 0:41
  • Ok after some reflection on past research I am comfortable with the assertion that Randal Schwartz popularized "fix all errors and warnings" as a testing heuristic in the book Effective Perl Programming. The Perl style guide books are the earliest examples I remember reading of what is now just called "good code style" in all modern interpreted languages — one more good thing we all stole from Perl. Answer accepted. Thanks Matt! – Noah Sussman Mar 17 '17 at 7:42
  • Perl has a history of being very forgiving leading to very subtle bugs. Hence it makes sense to tighten up a LOT. As for pre-ANSI C. Right now I work with Java code in IntelliJ and the editor is so helpful in finding out stuff that just minor changes introduce dozens and dozens of warnings of things that either need minor tweaking or deliberately needs to be disabled. Hence this is highly dependent on your working environment. – Thorbjørn Ravn Andersen Mar 17 '17 at 14:59
  • 1
    Steve McConnell's advice in Code Complete predates this by five years. – Andrew Medico Mar 19 '17 at 17:43
8

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

8

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.

  • 1
    Thank you for identifying Lint as possibly originating in 1977 that in itself is quite interesting to know. – Noah Sussman Mar 17 '17 at 10:26
  • 4
    It is perhaps noteworthy that Lint was conceived because K&R C and its compilers were very permissive. There were not enough errors, let alone warnings. Diagnostics are a valuable resource and should be fully exploited. Many postings on SO could be avoided and much valuable time could be spent playing games instead of answering superfluous questions if students would be taught to use "-Wall -Werror" on day one. – Peter - Reinstate Monica Mar 17 '17 at 14:41
  • 1
    When I learned C in the early 80s by working through K&R, I was taught that being lint clean was a good practice. Even in 1985 a typical C compiler did not provide a lot of useful warnings. It was a common practice among the people I learned from to include a lint step in the Makefile. As I moved from academia to industry, my early mentors taught me to fail early and loudly, and barring that, to put design effort into log file content and error messages. – RBerteig Mar 17 '17 at 21:57
4

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 {...}"?

3

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.

  • Thanks for the detailed response but my question was not whether or not you found it useful to know who created the meme "fix all warnings and errors." I am a historian of software and particularly of software testing. SQA SE is one of the tools I use to mine cultural and professional intelligence from the internet. Hope this helps to understand why the question is useful. – Noah Sussman Mar 16 '17 at 21:46
  • 1
    It think it resulted from common knowledge under software development teams. Any team writing software should come to this conclusion as it will bite them eventually. It is not like it is an invention that is not obvious. If you never clean your house you will run into trouble, everyone knows that. It is not like someone made that up and now the whole world owes this person gratitude for this idea. Everyone will eventually conclude that cleaning your house once a while is a good practise. – Niels van Reijmersdal Mar 16 '17 at 21:51
  • 2
    @NoahSussman Maybe it is a good idea to include the context "I am a historian of software" in your question. It would have made it much clearer why you are asking it. – Niels van Reijmersdal Mar 16 '17 at 21:52
3

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.

  • 1
    One of my favorite memories of Etsy circa 2011 was inviting Rasmus to review our PHP logs. He issued over 60 high-priority Jira tickets that week and I never saw him at the computer that week when he wasn't mumbling under his breath and looking annoyed! Needless to say when Rasmus tells you to fix a PHP log message you drop everything and fix it and that's what we did too! Monitoring and anomaly investigation were so much easier after that one week, and continued to become easier from that point forward. Continuous improvement was empowered by removing all that log noise! – Noah Sussman Mar 17 '17 at 7:38
2

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"

2

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.

  • The major benefit of Fix It As Soon As It Appears is that you soon get into the habit of writing code that doesn't have warnings and/or errors. Then you only need to address ones that you have never seen before - more interesting and less effort. Likewise, writing testable and maintainable code - once it's a habit it is easy and more productive not less. – Steve Barnes Mar 22 '17 at 19:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.