TODO注释有意义吗？ [关闭]

#1 楼

我倾向于对必须发生的事情使用// todo注释，但是我不能立即这样做。

但是，正如您所说，并不是每个人都对它们勤奋，并且像许多评论一样，它们会随着时间的流逝而腐烂。 br />
我会说这更多是个人喜好-只要您记录需要做的事情并继续进行下去，无论它在// todo，便笺还是白板中都没关系（在这种情况下，它们最终也可能不被采取行动）。

#2 楼

现代的IDE能够识别TODO注释，并且它们在自己的面板/窗口/选项卡中是可见的，因此从理论上讲它们不会丢失（我在思考Eclipse和Visual Studio，我都知道他们能识别出它们）。

您甚至可以配置其他注释词，例如FIXME，BEWARE或您要自定义的其他任何内容。但是，您项目中的其他开发人员将必须以相同的方式自定义他们的IDE。

现在，我写了《理论上》，因为尽管没有丢失，但TODO经常与不需要的东西相关该应用程序“目前”可以正常工作。而“此刻”可能会持续5分钟到5年，具体取决于项目的类型/规模：-)

最后，在我看来，将它们包含在代码在正确的位置，而不是在代码之外的其他地方，恰好回答了“我应该在哪里进行更改”这个问题。并且TODO的所有者被认为是一种好习惯。

#3 楼

这可能是有道理的，至少我有时会使用它们。关键是要使用一致的标签，例如TODO或FIXME，以便通过简单的文本搜索即可轻松找到它们。 ：

ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable

如果代码执行了应该执行的操作，并且没有人抱怨，那么该注释不会造成任何危害。如果有时间美化代码，则可以从搜索FIXME标签开始。

#4 楼

在我的行业中，鼓励开发人员创建JIRA（或其他）条目，而不要发表评论，因为不是每个人都有机会看到// todo条目。但是有时候在大型项目中，会按照以下方式定义自定义属性：

br />

[AttributeUsageAttribute(AttributeTargets.All, AllowMultiple = true)]
public class DeveloperNote : Attribute
{
    public DateTime EntryDate { get; set; }
    public string Description { get; set; }
    public DeveloperNote(int year, int month, int day, string desc)
    {
        EntryDate = new DateTime(year, month, day);
        Description = desc;
    }
}

更高的起伏可以自动收割。对于简单的// todo提醒来说，这可能会显得有些矫kill过正，但它确实有效。它还需要一个.NET平台。

#5 楼

根据我的经验，这取决于。主要因素是团队是否纪律严明，可以跟进这些“小”评论。如果他们这样做，那么他们是有道理的。如果他们不这样做，那么这些评论只会浪费时间，您可能需要研究其他选项，例如故事卡。

我个人有时会使用TODO注释，但它们通常寿命很短，而且我通常只有很少一部分，例如一，二或三。在代码库中，我将它们更多地用作标记。如果我等了太久才照顾他们，那么我会忘记我认为我需要做的事情。类似。对一种任务使用一种机制。

#6 楼

我过去曾经写过它们，但是我发现您通常不会跟进它们。

因此，现在我只用它们来标记我要完成的事情。忙着。例如，我实现了一个新功能，并注意到我使用的功能有一个小错误；我制作了一个FIXME来解决此问题，以避免在当前任务中出轨。

为了帮助我，如果代码中有FIXME，我们的CI版本将设置为失败：-)。 >
如果您发现无法立即解决的潜在问题，请为它们打开故障单/错误/问题。这样，可以像对待所有错误一样对它们进行优先级排序。我觉得这比在bug数据库中有一些问题以及在代码中有一些问题（如TODO）要好得多。 >

#7 楼

TODO只是评论的子形式。如果作者完全了解要传达的内容和方式，那么评论将很有用。几年后，这里也可以少量使用幽默感，以使维护者感到高兴。令我印象深刻的是，它已经投入生产并在维护中存活了16年。因此请注意，您的代码可能会持续很长时间。对意图，未来需求等进行的评论可以大大帮助从现在开始多年以来首次看到您的代码的人。

#8 楼

如果您编写TODO或FIXME的想法是有人在不确定的将来使用该代码时，其他人将对其进行修复，那么我想说就不要打扰。他们会乱扔代码，并使收集此信息的IDE的报告部分混乱。

为了使它们有用，它们应该提供一种将代码标记为（非常）不久的将来的方法，以便您可以更快地恢复到适当的状态。换句话说，您将它们放置在代码中只是为了尽快将它们删除。

任何寿命更长的东西实际上都应该放在它所属的错误库中。生活中有足够的噪音，别再制造新的事物而引起别人的注意。

我的2美分

#9 楼

我认为TODO的评论在某种程度上是有意义的。尤其是如果您要反复工作（这在敏捷和TDD商店中很常见），那么您不久就会意识到需要一些东西，但是您不想绕开这一步就此实施。 br />
丑陋的是当这些注释保留在代码库中时。在积极地使用某项功能时，最好将它们保留下来，但是一旦您接近完成该功能，就应该着重于摆脱它们。如果您不想完成用适当的有效代码实际替换它们的工作，那么至少要考虑到相关功能。借用@JoonasPulakka的示例，其中代码最初显示为

ConnManager.getConnection("mydatabase"); // FIXME: DB name should be configurable

，您可以将其更改为类似
/>目前，GetDatabaseName（）是一个存根，只返回您开始时使用的相同字符串。这样，将来就可以明确地进行扩展，并且您知道在那里进行的任何更改都会反映在需要数据库名称的任何地方。如果数据库名称是一般通用名称，则可以大大提高可维护性。

我个人使用自己的关键字而不是严格的TODO，尽管目的是相同的：标记事物我知道需要重新审视。另外，在签入代码之前，我会在全局源代码中搜索该关键字，该关键字的选择通常应使其不出现在代码中的任何位置。如果找到它，我知道我忘记了什么，可以继续进行修复。

至于在注释中包含程序员名称/签名，如果您拥有源代码版本控制系统（您知道，对吗？），我认为这太过分了。在这种情况下，其怪异功能会告诉您添加评论的人，或更准确地说是谁最后一次检查了涉及评论的更改。例如，在Visual Studio中，这可以通过使用源代码控制功能中的“注释”功能轻松实现。

#10 楼

通常我不//做TODO注释，而是将所有注释保存在单独的文件中。仍然无法找到/编写在线软件来轻松管理它们，因此TODO文件对我来说仍然是最有用的，因为即使在很短的时间后打开项目，我都忘记了现在该怎么办，然后我查看TODO文件并完成工作。我有“ filename.cpp 354：重新编码此bla bla bla”，然后在文件中搜索// TODO注释会更加有用。我懒惰的时候就做// TODO耳环，但是我只是从源文件中删除了那些旧的// TODO-s，并且在项目运行良好时不修复它们。我强烈建议将所有// TODO从源移到单独的位置，并将它们与其他待办事项保持在一起，以便您可以轻松地优先处理任务。当您将所有TODO放在各种文件和项目中时，优先级确实是一件难事。

#11 楼

与其他一百万种创建任务列表的方式相比，待办事项注释的巨大优势在于，待办事项注释随代码一起传播，因此它们不会分离。

可能是更合适的地方像这样的东西是问题跟踪器，而不是代码。

#12 楼

我认为那很棒，但并不孤单。例如：

//TODO: ADD MY CLICK EVENT LOGIC
throw new Exception();
//Even a simple messageBox could suffice

这种方法非常谨慎。尽管我不得不说，养成引发异常以提醒您完成一些代码的习惯并不是真正最专业的方法。但这在某些情况下为我省了一笔钱，因为您认为自己已经完成了某些工作，甚至写下了您尚未完成的工作。

#13 楼

我强烈建议您将每个TODO或FIXME输入正式日志中。如果不是，则可以轻松搜索它们，并且应该在每次迭代中检查未完成的TODO和FIXME。然后可以对这些文件进行分类，并设置为立即补救，或者团队可以计划在适当的时间对其进行修复。解决后，如果以系统的方式进行处理，它们将失去效力。

#14 楼

如果您尝试提交具有新TODO的代码，则IntelliJ实际上会警告您。因此，您始终可以将TODO解释为“这确实应该在我提交时发生”。

#15 楼

当您将“ TODO”作为注释的语义标签时，我认为它们确实有意义。

在我公司的编码标准中，我们指定负责开发人员的姓名缩写必须包含在TODO中（即，我将输入“ SAA TODO：”）。我认为这很有用，至少是作为一个约定，因为否则有一种诱惑，那就是将不合格的代码留在TODO注释中，以供将来的开发人员使用。将这些注释添加到任务列表中，以类似方式处理它们，以生成内容，并且不会被无限期遗忘。

#16 楼

一个更令人讨厌但又有效的方法可能是将待办事项注释转换为编译器消息，这样您和其他所有人都可以在编译程序时看到它。

在Delphi中：

{$message 'todo: free this thing when you know its not going to blow up'}

#17 楼

以我的经验，应该使用TODO来指示一段代码不可用，并告诉读者使其（在本地或其他地方）可用是什么。

TODO注释不应该用于表示如果以某种方式修改某些代码会更好。例子包括脏代码，如果重写，它们将更易于维护，或者尚无人需要的额外功能。这些注释会堆积起来，使grep TODO返回无用的结果。