How to leave debugging information in code before it hits production or even after?

Question

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.

Answer 1

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.