Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
1  
Are his debugging statements wrapped with #if DEBUG? –  Anna Lear Sep 25 '11 at 14:33
    
No, would that be useful? –  Adam Butler Sep 26 '11 at 2:50
    
It would prevent the code from running when the application is built in Release mode and given to customers/deployed somewhere, which could be the best of both worlds for you and the other developer. –  Anna Lear Sep 26 '11 at 2:54

5 Answers 5

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.

share|improve this answer

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.

share|improve this answer
    
"shouldn't change the semantics of the codebase to debug things." Good point, but too weakly stated. Perhaps you should have said "Changing the semantics to -- allegedly -- debug things can't possibly work. You changed the semantics. You're not "debugging"." –  S.Lott Sep 25 '11 at 21:15

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.

share|improve this answer

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.

share|improve this answer
1  
How is stepping through things the preferred method? It is pretty slow and doesn't really work in many environments . . . –  Wyatt Barnett Sep 25 '11 at 14:45
    
@WyattBarnett Yes, it's slow, but it encourages the developer to read the code and carefully observe the value of variables. In what environments is it not supports? I've used stepping-debuggers in Java, Scala, C, C++, and Scheme. I know that Visual Studio provides it for all of the .NET languages as well. That should cover most code produced by corporations. –  Thomas Owens Sep 25 '11 at 17:32
    
@WyattBarnett I have to disagree with you. If you implement new code and it is more than just a few added lines, I like to set a breakpoint right before that code is utilized. Then I step through it line-by-line to ensure that the values and code flow are what I was expecting when I originally wrote it. –  user29981 Sep 25 '11 at 17:32
1  
The other side of the coin is that there are bugs which are very difficult or impossible to catch using breakpoints and the debugger (e.g. concurrency bugs), whereas debug logs can be a great help in these cases. –  Péter Török Sep 25 '11 at 19:53

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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