3 ms·

printf()-based debugging is okay when these statements are temporary, or when they are only present in development branches. At $previousjob we had a guy who l

printf()-based debugging is okay when these statements are temporary, or when they are only present in development branches. At $previousjob we had a guy who literally spent a year adding printf() statements everywhere to production code in order to help himself understand the existing code base he had to work on. "It's not printf()-debugging, I'm doing extensive permanent instrumentation". He even developed a whole framework for printf()-based debugging, to print messages in an artistic way. The actual code became very hard to read due to the omnipresence of debugging cruft. He also made the whole test suite dependent on the output of the debugging printf() debugging statements, making any kind of refactoring impossible. I showed him how to use gdb and bought him a hard copy of the dtrace book, but it didn't help.

pmontra 11y ago
Maybe he should have added log points instead of printfs. He could have used an existing logging framework instead of writing his own. Still 1) writing your own code is a valuable learning experience 2) wasting time is a drag on the team and on the company so he should compromise between learning and producing (but where was management?) 3) too much logging pollutes the code too
akkartik 11y ago
Oddly enough, I've spent some time working on "white-box" tests that check the log. It takes taste to do well: you have to be careful to log what your program figures out about the domain, rather than just random details. Done right, I find it actually helps refactoring. My unit tests now usually call some top-level function rather than just the sub-component they test. As a result I can make radical changes, like going to client-server or from sync to async, without having to change any tests. More details: http://akkartik.name/post/tracing-tests http://akkartik.name/post/tracing-tests
cwilkes 11y ago
I would ask myself why he felt he needed to add such statements. Provided he isn't an idiot it is probably because the flow was hard to understand. Was that his fault? I've found that if I can't understand the code it is because it is unnecessarily complex or, to mimic an above poster, there's too much state going on. Refactor to remove confusion. Imagine yourself as a newbie asked to support such thing in production. Could you do it? If no why not?

pmontra 11y ago

Maybe he should have added log points instead of printfs. He could have used an existing logging framework instead of writing his own. Still 1) writing your own code is a valuable learning experience 2) wasting time is a drag on the team and on the company so he should compromise between learning and producing (but where was management?) 3) too much logging pollutes the code too

akkartik 11y ago

Oddly enough, I've spent some time working on "white-box" tests that check the log. It takes taste to do well: you have to be careful to log what your program figures out about the domain, rather than just random details. Done right, I find it actually helps refactoring. My unit tests now usually call some top-level function rather than just the sub-component they test. As a result I can make radical changes, like going to client-server or from sync to async, without having to change any tests. More details: http://akkartik.name/post/tracing-tests http://akkartik.name/post/tracing-tests

cwilkes 11y ago

I would ask myself why he felt he needed to add such statements. Provided he isn't an idiot it is probably because the flow was hard to understand. Was that his fault? I've found that if I can't understand the code it is because it is unnecessarily complex or, to mimic an above poster, there's too much state going on. Refactor to remove confusion. Imagine yourself as a newbie asked to support such thing in production. Could you do it? If no why not?