The best way to clean things up is to avoid them getting dirty in the first place

From WikiContent

Jump to: navigation, search

Warnings are useful. You get warnings from your IDE when you write something that might be a bug. You have probably made your program print out warnings or error messages when something goes wrong.

But too often, we down in the sheer volume of warnings. Then it's impossible to separate the relevant and important warnings from the noise.

To make warnings useful again, I use a zero-warning tolerance policy. Even if the warning is irrelevant, I fix it. Otherwise, I will have to decide that it's irrelevant every time I encounter it. If there are warnings I just don't care about, I turn them off in my IDE. Ignoring things is mental work, and I need to get rid of all the mental work I can.

Getting the warnings out of an existing project the first time requires some work. But it's worth it.

In the same way, the logging messages your program writes gives you useful information about the state of the system. What happens if you watch the "error" level log of your system? Or the "warning" level? Or the "info" level?`

I don't want anything in my error log that I wouldn't want to be woken up for in the middle of the night. If you have 24/7 support people on your project, you might actually try that experiment: After being woken up a few times by "checking customer status" or other irrelevant messages, there's a lot of motivation for logging at the right level.

I use the following guidelines: I should be able to watch the "info" level log of the production system tick along at the rate of traffic of the system. During normal operation, there shouldn't be anything logged at "warning" that I don't care about. And there shouldn't be anything logged at the "error" level that I'm not willing to be woken up in the middle of the night for.

The best way to make sure that you don't start getting pollution in the log is to use them. Send error logs from both production and test installations via email (or SMS!) to the development team. Look at the "info" and "warning" logs every once in a while.

When something appears that you don't want to see, fix the code. Don't wait for a big cleanup. Fix it right away. If it's not your code that logs, fix the filters in your log configuration.

Warning from your compiler and from your code are useful. You just need to get rid of the noise to start noticing them.

By Johannes Brodwall

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Programmer Should Know home page

Personal tools