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:
- 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.
- 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.
// 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.