Yeah, I stopped using comments as a code ON/OFF switch when I started using git.
But then I handed over my project to someone without OCD and now the repo is full of code inside comments.
And because I don’t use git stash properly enough, in some projects, my stash is 3+ stacks long, with almost the same changes in each of the stashed entries.
In general, I’m with you
But sometimes I need to revert/comment out a code block, because another code part isn’t finished/working as it should.
Sure, it clutters code, but if I just comment out a function call and temporarily replace it with the workaround, it should imho stay in code.
Else the workaround will stay forever and the commented out code will act as a reminder, that this part isn’t clean yet.
But maybe it really is a case by case thing, where sometimes it’s better to branch it out for later merge - although that can get really messy, while having the future implementation commented out, others will also see, how it is supposed to work and don’t try to further extend the workaround, which makes future merging hell
Out of interest, how would your best practice look in such cases?
This. Commenting out code is bad practice
Yeah, I stopped using comments as a code ON/OFF switch when I started using
git.But then I handed over my project to someone without OCD and now the repo is full of code inside comments.
And because I don’t use
git stashproperly enough, in some projects, my stash is 3+ stacks long, with almost the same changes in each of the stashed entries.In general, I’m with you
But sometimes I need to revert/comment out a code block, because another code part isn’t finished/working as it should.
Sure, it clutters code, but if I just comment out a function call and temporarily replace it with the workaround, it should imho stay in code.
Else the workaround will stay forever and the commented out code will act as a reminder, that this part isn’t clean yet.
But maybe it really is a case by case thing, where sometimes it’s better to branch it out for later merge - although that can get really messy, while having the future implementation commented out, others will also see, how it is supposed to work and don’t try to further extend the workaround, which makes future merging hell
Out of interest, how would your best practice look in such cases?
I would make it a TODO so that it’s clearly temporary and so the linter bugs me about it until the intended permanent code is restored.
In general I prefer to keep separate branches and maybe a draft PR open for visibility for that kind of situation, though.