In the past month or so I’ve been working on a code base that’s been around the block a few times. Some of the code was inherited from other projects where it was already ancient. Other code is just code that has been in the project forever.

I’ve noticed that this code—production code and tests—is very chatty. I mean, I can’t run a test without War and Peace being written to the console. My guess is that this due poor tests.

When the code is unfamiliar, we have a few options to get our heads around it. The first and best option (in my opinion) is to run the code’s extensive and well-maintained test suites. The tests will serve as documentation for the code in its current state.

What if we don’t have those tests? I guess we start reading through the code, using the debugger, and output statements to the console. See where I am going with this?

Writing output/debug statements is fine for short-lived (think minutes) testing/code archeology. Once you answer your particular question, get rid of it. If you need that output to test something, put it in a test. If the output is something you’d like to have when the production code is running, log it. Either way, those output statements should not get committed.

Why? Software is complex. We try to reduce the complexity. Tests and production code that spew line after line to the console when it is not needed add complexity. Consider a test that prints a stack trace from an exception to the console, yet passes. How are you going to feel about the test? The production code?