Value of maintaining debug outputs

Question

A developer on our team litters his code with debug outputs. He passes many parameters into methods that are only used for debugging.

Personally I find this clutters up the code. If I need to debug something I prefer to use breakpoints and the watch window instead of reading through all the debug output.

I am making major changes to several classes written by this other developer, should I maintain his debug outputs or can I justify removing them?

I have only been in this team for a few months and don't want to upset this developer but also I expect he will rarely be updating this part of the system.

Answer 1

Considering you are new to the team you should be extremely confident in your changes first.

Standards help in situations like this. Talk with others on the team and find out what is typical in the group. Share your quality or efficiency suggestions openly with the team.

If your team has a general agreement that segments of code are "owned" by a particular developer then ask them to review code changes. It's a good practice to have someone review code anyway and this is a great way for newer team members to gain trust.

Answer 2

I think the only thing really wrong here is the extra parameters which are used only for debugging -- you really shouldn't change the semantics of the codebase to debug things. Having lots of debug output is generally a good thing beyond that.

In terms of operational effects, lots of Debug.Write() statements don't hurt a fly; they get passed over by the compiler if you are not passing the DEBUG flag into it. And, unlike your breakpoints, they survive with the codebase so if you have a regression you don't need to remember where you set the breakpoint and what you were watching. Whereas with the debug output you will always have your instrumentation.

Answer 3

Yuck, delete them and when you find a few hundred more delete them too. Especially if they're commented out. It's unlikely you're going to have debug exactly the same thing as your colleague did however many years ago he added them and all they do is make everything more difficult to read.

In the interests of peace in the workplace it might be best to ask your colleague first if that's okay as you're making major changes.

Answer 4

In development, yes, the use of a debugger and stepping through code, watching variables is the preferred method. It's a matter of code quality. Adding variables to method signatures and other debugging output is messy and introduces variability into the code. There have been defects that have been hidden (or revealed) just because an extra variable was introduced or a console print statement added.

However, there is something to be said for the use of logging to capture debug information, as long as that logging can be adjusted to the appropriate level of verbosity. I typically use something like log4j and various levels of logging. Based on what I'm currently doing, I adjust that level. During normal execution and use, I log at INFO or WARN. If I'm testing, I'll log at TRACE or DEBUG to get more information. This, coupled with the ability to watch variables and set breakpoints is invaluable.

Answer 5

Would branching be an option for your source control ? That way this developer could have a local branch where he can have his debug outputs without polluting the shared codebase.

However for the long term, it imho would be good to show him the benefits of using breakpoints-type debugging as well (one on one or during a "Lunch and Learn") and that gives him a chance to show the benefits of his method as well, but that can be tricky (e.g. if it's a senior developer who is well anchored into his own ways).