I have to say, I’m getting more and more frustrated by the bad code I have to write due to bad business circumstances.
I want clean, readable code with proper documentation and at least a bit of internal consistency and not the shoehorned mess of hacks, todos and weird corner cases.
Don’t just put “TODO”. If they’re in the final pull request, they need to mention a ticket that’s intended to fix that TODO. If you/your team decides it’s not important, then remove it and close out the ticket. Either way, you’re required to do something with it.
I have to say, I’m getting more and more frustrated by the bad code I have to write due to bad business circumstances.
I want clean, readable code with proper documentation and at least a bit of internal consistency and not the shoehorned mess of hacks, todos and weird corner cases.
I found a simple trick against this: just remove them. Accept it ain’t gonna happen man.
Well, yes, but the underlying issues still persist, so it’s not exactly a sustainable strategy.
It’s mostly a joke, but often when I find todos they’re so old they’re no longer relevant.
Of course you shouldn’t blindly remove todos.
Don’t just put “TODO”. If they’re in the final pull request, they need to mention a ticket that’s intended to fix that TODO. If you/your team decides it’s not important, then remove it and close out the ticket. Either way, you’re required to do something with it.