在评论中是否有“???”，“!!!”，“TODO”等标签？
我正在谈论评论开始时使用的特殊单词/标记，以便于评论或附加某些特殊含义，比如// TODO: Find out what to do about this error 。
一些标签的含义是明显的，如TODO和FIXME ，但是呢??? 和!!! ？ 有其他人吗？ 我问，因为我最近看到最近的两个，一些编辑，即Xcode，提供了一个简单的方法来find所有这些标签的评论。
如果没有这样的标准 ，我可以用描述任何公司本地政策的描述。 🙂
编辑 ：参考实际文档的奖励积分。
SO中的这些问题也可能有帮助：
- 你如何标记代码，以便你可以稍后回来并进行处理？
- #XXX是什么意思？
- 视觉工作室中的令牌：HACK，TODO …任何其他？
简短的回答：不。
很长的回答：
- 全球和官方？ 没有 。
- 全球非官方的（正如大多数开发者所使用的）？ 有点
- 每-IDE？ 通常， 是的 。
评论标记没有全球标准，但许多IDE（如果不是大多数IDE）默认定义了一些IDE，并且实现了允许程序员在必要时定义更多（自定义）IDE的系统。
这种系统以及默认令牌本身的实现在语法上有很大的变化，缺省定义的令牌量和令牌的“名称” 。 这一切都取决于IDE。
到目前为止， “最标准”的评论标记是TODO ; 几乎所有实现注释令牌系统的IDE都默认定义了至lessTODO 。 其他常见的令牌有： TOFIX或FIXME ， BUG和NOTE 。
这些标准的一些例子，在每个IDE的基础上：
- Visual Studio ：
HACK，TODO，UNDONE和NOTE。
默认情况下，Visual Studio包含以下标记：
HACK，TODO，UNDONE，NOTE。 这些不区分大小写。
- Eclipse ：
@todo，FIXME，TODO和XXX。
列表中默认包含四个常用string。
- Netbeans ：
TODO，FIXME等等。
“操作项目”窗口将自动扫描您的代码，并列出包含“TODO”或“FIXME”等词语的注释行，以及包含编译错误，快速修复和样式警告的行。
- IntelliJ IDEA ：至less
TODO。
默认情况下，任何以TODO开头的string（无论大小写）都被解释为TODO项目，并相应地突出显示。
- Code :: Blocks ：至less
TODO。
如果在CodeBlocks中打开源，可以通过上下文菜单命令“添加待办事项”将待办事项添加到列表中。 将在源代码的选定行中添加注释。
// TODO (user#1#): add new dialog for next release
- 骑士 ：默认的
TODO和BUG，但也间接暗示和解释了REVIEW，NOTE和HACK的用法。
多年来，我已经看到了使用这些types的评论中的一个（或多个）来描述应该在某个时刻执行的任务的代码库，例如作为“童子军规则”的一部分：
- 待办事项 – 一个简单的“待办事项”，应该在某个时候执行（但是经常停留在代码库多年）
- 评论 – 代码审查员应该注意的事项和注释 – 解释了为什么写了一段代码，以及底层的想法是什么
- BUG – 描述一个错误（这个错误可能也会logging在问题跟踪器中）
- HACK – 解释代码中的黑客行为
默认情况下，Rider将TODO和BUG识别为TODO注释。 为了增加对其他评论的支持，我们可以定义一个新的模式。 我们可以从Editor |下的设置中完成此操作 去做。
奖金：
如果它感兴趣的人，这是我使用的标准…
标签和语法：
-
@NOTE注意 – 表示任何有关值得注意的事情，但不涉及行动。 -
@TODO– 表示需要完成的事情，但这不是一个修复（可能或可能不重要）。 -
@TOFIX– 表示需要修复的东西（可能会或可能不会被破坏）。 -
@HACK– 表示已经完成的快速修复或解决方法，无论是必要还是方便，如果可能的话应该被replace或改进。 -
@DONE– 或者按照预期（取代以前的TODO，TOFIX或HACK），或者意外地发现了一些事情（某人发现了需要纠正或可以改进的新事物，#LikeABoss，刚刚去DONE了） 。- 这主要是针对内部（开发团队）文档，通知和/或确认目的，build议根据时间（每X天）或版本/构build（每隔一段时间），定期清理这些不可避免的累积X版本/构build）。 特别是在项目源代码公开的情况下，以避免混乱。
-
@UNDO– 表示在更改之后被破坏，并且（至less现在）需要被回滚到以前的版本。 -
@UNDONE– 表示事实上 （已经）回滚到先前版本的东西，无论出于何种原因。- 这主要是针对内部（开发团队）文档，通知和/或确认目的，build议根据时间（每X天）或版本/构build（每隔一段时间），定期清理这些不可避免的累积X版本/构build）。 特别是在项目源代码公开的情况下，以避免混乱。
-
@ASAP– 表示需要注意或做某事的事情。 -
@ISSUE– 表示任何需要注意或审查的问题，可能由其他人在团队中工作（需要同行评议）。- 例如，某人对某事有疑问或疑问; 或者指出某种改变可能是一个好主意; 或者某人由于某种原因不愿意变成
TODO或TOFIX的实际问题。
一个ISSUE基本上是一个需要注意的NOTE，而不是仅仅值得注意 ，但仍然（可能或可能）不涉及某个动作。
- 例如，某人对某事有疑问或疑问; 或者指出某种改变可能是一个好主意; 或者某人由于某种原因不愿意变成
-
@GLITCH– 表示程序的input或stream程情况会导致奇怪或意外的行为，但不会彻底破坏程序或输出的数据。 -
@BUG– 表示程序的input或stream程情况导致程序彻底崩溃（死机，崩溃或其他严重问题）或输出（未能输出或输出错误数据）的情况。
这些标签可以组合使用，也可以在一个:分隔符模式之后使用额外的“说明符” ，不包括后续标签的@ ，也可以包含引用特定团队成员的specifier ，并注意第一个标签的重要性级别。
例如：
- 一个需要
ASAPTODO会写成@TODO:ASAP: This [blablabla] needs to be done as soon as possible because [blablabla]! - 可能会
GLITCH导致GUI组件闪烁几毫秒的次要GLITCH，并且仅在非常特定的条件下才会发生。- 作为一个
ISSUE，甚至是一个NOTE而不是GLITCH标签的隐含更高的优先级，比如@ISSUE:GLITCH: The [blablabla] component flickers for a bit when this function is called with [blablabla] as values - 或者作为
GLITCH，但是通过预定义的“说明符”指示低优先级，比如@GLITCH:LowPriority: ... [Continues like the example above]
- 作为一个
所以sintax规则被简单地归纳为：
@MAIN_TAG:[SUB_TAGS|[@]Specifiers:] Message
例子：
//@TODO: Implement a delta-time loop class to replace this //@TOFIX:ASAP: Accumulator doesn't have enough precision; change type to double, and deal with the cascading effects throughout the code //@NOTE: 'lhc' stands for "Large Hadron Collider" in the function/method below //@ISSUE:Bob:@Scott: This is where I'm missing an '*Exception (...)'; probably a missing import. //@DONE:Scott: I've sent a copy of the missing lib to Bob, and explained him how to use it. Issue removed //@ASAP: Replace or add and handle an alternative to the usage of 'BrandNewLanguageFeature' from the code below. We need to support an older version.
我们在Eclipse中使用Java，因此使用默认的Eclipse标签TODO，FIXME和XXX。 我使用XXX时，某些东西不是真的坏了，但很奇怪，或者应该以不同的方式完成。
在Visual Studio中，有一个“任务列表”，默认标签（在VS2010上）是“HACK”，“TODO”，“UNDONE”和“UnresolvedMergeConflict”。 所以我会build议使用这些如果您使用Visual Studio。
这可能会有所帮助：
http://en.wikipedia.org/wiki/Comment_%28computer_programming%29#Tags
我通常在我的vim配色scheme中join“NOTE：”，因为许多不包含它。
是的，它叫Codetag 。
在编码媒体文章之前，之后和之后请参阅不要忘记 。
我用 ！！！ 对于在提交之前必须解决的代码。 我用 ？？？ 对于奇怪的/应该做不同的/只是看起来不正确（总是有一个解释）。
我们使用Doxygen标签\todo 。
你select什么，确保你坚持到底 。 所以，如果你去与/ / // TODO确保它永远是这样，永远不会/ / //TODO或/ / / /。
为什么？
如果只是一个string，一个简单的search将会find代码中仍然存在的所有地方，并且可以更容易地跟踪它们。
理想情况下，你不应该有任何 – 但我们不是在一个理想的世界中生活（或工作）。
没有，虽然TODO更常见。
有关详细的研究论文：
Storey，M.-A.，J. Ryall，I. Bull，D. Myers，J。Singer，“TODO或To Bug：探索任务注释如何在软件开发人员的工作实践中发挥作用”，Proceedings of the国际软件工程会议，德国莱比锡，2008年5月10 – 18日。
在您还想参考一个文档时，“官方”（Oracle）Java代码约定（ http://www.oracle.com/technetwork/java/codeconventions-137265.html#395 ）是：
10.5.4 Special Comments Use XXX in a comment to flag something that is bogus but works. Use FIXME to flag something that is bogus and broken.
