3

Usually, I open a git branch to work on some task. When I finish the task I send it to be reviewed. Then it's sent to central staging git branch which contains all tasks that have passed review. Our QA team does qa for tasks in the staging branch.

Before sending my work for review I usually have print statement in quite a few places. I may have debugger statements (which is a Javascript specific feature but may have its parallels in other languages). In addition in Javascript there're several ways to return an object from a function, for example:

const func1 = () => ({ a: 1})

or

const func2 = () => {
  console.log('from func1')
  return {
    a: 1
  }
}

The first looks cleaner and may be used in production code however the second version allows to add some statements before return like console.log. Perhaps there're parallels in other languages for this feature as well.

So before sending my work I remove all print statements and make sure functions conform to the style of func1. However, during the review I may have to change my code and then I would need again my debugging information to make sure everything works as expected or to troubleshoot bugs which may arise as a result of changing my code. I may need debugging information again if QA team finds a bug. Lastly, the code may go to production and in 2 months a bug will arise and it would be helpful to have all the debugging statements ready for the code section that the bug originates from.

Obviously it's a pain to manually re-insert debugging statements each time and/or change functions of type func1 to func2 type, so I'm wondering what's the best practice here? These are some ideas I've been thinking about:

  1. Make a commit that contains debugging statements before the final "production" commit. Cons: the reviewer shouldn't waste time for debugging statements, will always be confused by 2 commits, I will need to remember to remove the debugging statements eventually, git history will become more bloated and confusing, potentially git conflicts may arise between my commits.
  2. Have 2 git branches: one containing commits with debugging info, another without. Cons: each time I will need to change something in my code I will have to do it in the "dirty" branch, then remove debugging statements and have a "clean" branch. This quite a manual process and prone to errors as well.
2
  • 2
    Are you preprocessing (minimize, gzip, et.al.) your JavaScript code before serving it? I did once implement a reprocess routine that would look for lines that had a // DEBUG comment at the end and removes them. The result of the processes was cached, of course, and only updated if the original file changed. That was all handled in server side code.
    – Theraot
    Nov 30, 2019 at 19:56
  • 1
    @Theraot we do preprocess code (everything you mentioned). Perhaps we can use stackoverflow.com/questions/41040266/…
    – Yos
    Nov 30, 2019 at 19:58

1 Answer 1

6

This is exactly why level logging was invented. You leave the code in, you just turn it off. It exists for Javascript.

If you want to use casual debugging code like console.log() I highly recommend using //TODO remove comments. I use the comment even when I never intend to check the code in because it makes clear that it doesn't belong here. What I intend and what actually happens sometimes aint the same.

7
  • I guess you're saying that we need to abandon our style of not having console.log in code and specific style (like func1). That's a valid idea.
    – Yos
    Nov 30, 2019 at 19:54
  • 1
    This may be a dumb question, but shouldn't automated tests cover this? You should be able to write a new test if something gets kicked back to you and not logging statements.
    – unflores
    Nov 30, 2019 at 20:32
  • 2
    @unflores manual testing and debug code existed long before automated testing. Just because cars exist don't expect bicycles to disappear. Knowing how to do things the old school way still comes in handy. Just don't bike on the freeway. Nov 30, 2019 at 20:34
  • To be honest I was mostly referring to what you call “casual debugging”. So adding todos then removing them and then if there’s a bug that qa found adding them back manully. Is there a good solution to that?
    – Yos
    Dec 1, 2019 at 5:33
  • 1
    @Yos I've used a mix very successfully. Just because you have the ability to create trace log code doesn't mean that's how all your debugging is done. I suggest you give yourself a chance to play with it and see how it feels. Much of my trace log code began life as casual debugging code that I decided was worth keeping around. That meant I had to upgrade it into something others would understand. I certainly didn't do that with everything. Most of my debug code ends up in what I call my 'junk drawer'. It's where I send code to die. Dec 1, 2019 at 5:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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