I have mixed feelings on this one... The first example removing comments is probably a poorer example, as I don't feel the latter is cleaner.
Not having TODO's is heavily arguable, I'd go so far as to say *DO* add todo, but reference a backlog/issue number related to the issue/pbi you create to refactor the TODO item.
// TODO #803 - Break off into separate module and refactor
I completely agree with exit early... as to one of the rebuttal comments on complex returns... then break it up into smaller chunks of independent functions.
The same thing. As for TODO it’s completely out of row.
Zero TODO policy might be a good practice from the standpoint of issue tracking and project management.
From the perspective of code quality a better argument would be “todo’a in code encourage people to postpone refactorings and write bad code”. That’s arguable, but is at least about code quality, not something different.
I have mixed feelings on this one... The first example removing comments is probably a poorer example, as I don't feel the latter is cleaner. Not having TODO's is heavily arguable, I'd go so far as to say *DO* add todo, but reference a backlog/issue number related to the issue/pbi you create to refactor the TODO item. // TODO #803 - Break off into separate module and refactor I completely agree with exit early... as to one of the rebuttal comments on complex returns... then break it up into smaller chunks of independent functions.