你肯定遇到下面场景：
您正在编写代码并决定在未来添加一项功能。
于是增加了代码
TODO: featrue
您正在编写代码并且有一个错误。
TODO: bug
你正在编写代码，并且有一些东西需要 reviewed、refactored 或 noted。
TODO、TODO、TODO。
停止使用 TODO 处理注释中需要您稍后执行的所有操作。
并不是说“注释不好”或者 “你应该只使用问题跟踪替代”。而是有一些方便的，更具描述性的替代方案：
| 术语 | 描述 |
|---|---|
| FIXME: | something is broken |
| HACK/OPTIMIZE: | the code is suboptimal and should be refactored |
| BUG: | there is a bug in the code |
| CHECKME/REVIEW: | the code needs to be reviewed |
| DOCME: | the code needs to be documented (either in codebase or external documentation) |
| TESTME: | the specified code needs to be tested or that tests need to be written for that selection of code |
等等！所有这些提示不仍然是 TODO，只是名称不同！
从技术上讲，是的。但是使用更广泛的术语选择的价值在于您（以及因此与您合作的所有其他程序员）能够更准确地描述您需要“做什么”。
您现在可以按这些更具体的注释进行过滤。您甚至可以根据类型对更改进行优先级排序。您还可以使用出色的 VSCode 插件（例如 TODO Highlight 或 TODO Tree）来自动突出显示所有这些注释。
这不是一个超级严肃的文章。您仍然可以使用经典的 TODO 及其他方式轻松地以多种方式描述您想做的事情。
对于大多数情况，TODO 工作得非常好。TODO 可以快速轻松地搜索。只需确保您还将任务添加到您的 GitHub/Jira/Asana 问题跟踪（您甚至可以在评论中链接到该问题）。
最后，最重要的是您以相对及时的方式解决这些任务 - 您不希望您的项目最终像 Linux 代码库那样具有 3000 多个可追溯到十年前的 TODO。
但是，请记住所有这些替代方案都存在 - 随意使用它们！
谢谢阅读 ：）
