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

我正在做一个相当大的项目，并承担了为它做一些翻译的任务。有很多标签没有被翻译，当我浏览代码时，我发现了这小段代码

//TODO translations

这让我想到了对自己（和其他人？）的这些评论的意义，因为我感觉到大多数开发人员在完成某些代码后，就会按照原本应该做的去做，直到他们拥有完为止进行维护或添加新功能。因此，这TODO将丢失很长时间。

编写此注释是否有意义，还是应该将其写在白板/纸上/其他仍以开发人员为重点的地方？

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

我还确保追逐它们-搜索它们（Visual Studio具有一项不错的功能，它将为您列出此类注释）并确保已完成操作。

但是，正如您所说，并不是每个人都对它们勤奋，就像许多评论一样，它们会随着时间的流逝而腐烂。

我会说这更多是个人喜好-只要您记录需要完成的事情并继续进行下去，无论它在// todo，便签纸还是白板（它们也可以最终不正在采取行动）。

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

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

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

最后，我认为在代码中的正确位置正确地回答“我应该在哪里进行更改”比在代码外部的其他位置更有意义。

编辑：因为它写在Wikipedia的有关评论的文章中，包括TODO的日期和所有者，这被认为是一种好习惯。

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

例如，“快速处理”解决方案很容易标记，例如：

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

如果代码执行了预期的操作，而没有人抱怨，那么注释不会造成任何危害。如果有时间美化代码，则从搜索FIXME标签开始很容易。

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

[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;
    }
}

然后可以用这种方式修饰方法...

[DeveloperNote(2011, 12, 13, "Make the db connection configurable")]

更高的起伏可以自动收割。对于简单的// todo提醒来说，这可能是过分的，但是它是有效的。它还需要一个.NET平台。

TODO只是评论的子形式。如果作者完全了解要传达的内容和方式，那么评论将很有用。几年后，这里也可以小剂量使用幽默感，以使维护者满意。

去年我接到电话，说我的某些代码已经退休。令我印象深刻的是，它已经投入生产并在维护中存活了16年。因此请注意，您的代码可能会持续很长时间。对意图，未来需求等的注释对于帮助从现在起数年后首次查看您的代码的人有很大帮助。

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

我个人偶尔会使用TODO注释，但它们通常寿命很短，通常只有一，二或三个这样的注释。在代码库中，我将它们更多地用作标记。如果我等待太久而无法照顾他们，那么我会忘记我认为需要做的事情。

我总是希望不使用这些内容，而使用适当的故事卡或积压或类似内容。对一种任务使用一种机制。

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

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

为了帮助我，如果代码中有FIXME，我们的CI版本将设置为失败：-)。

如果您发现无法立即解决的潜在问题，请为其打开故障单/错误/问题。这样，可以像对待所有错误一样对它们进行优先级排序。我觉得这比在bug数据库中有一些问题以及在代码中有一些问题（如TODO）要好得多。

然后，您可以选择将具有错误ID :-)的TODO放入。

我认为TODO评论在一定程度上是有意义的。特别是如果你反复工作（如在敏捷和TDD商店常见），就会有事情，你认识正在准备不久将需要的，但你不希望使绕道来实现，然后有。

丑陋的是当这些注释保留在代码库中时。在积极地使用某项功能时，最好保留它们，但是一旦您接近完成该功能，就应该着重摆脱它们。如果您不想完成用适当的有效代码实际替换它们的工作，那么至少要考虑到相关功能。借用@JoonasPulakka的示例，其中代码最初说

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

您可能会将其更改为类似

ConnManager.getConnection(GetDatabaseName());

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

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

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

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

为了使它们有用，它们应该提供一种为（非常）不久的将来添加代码书签的方法，以便您可以更快地回到正确的状态。换句话说，您将它们放置在代码中只是为了尽快将其删除。

实际上，任何寿命更长的东西都应该放在它所属的Bug库中。

我们的生活中有足够的噪音，不要在其他地方需要引起人们注意的情况下制造新的事物。

我的2分

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

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

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

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

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

诸如此类的东西可能更合适的地方是问题跟踪器而不是代码。

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

最后，一旦修复，则需要将其删除-如果解决后仍未系统地消除它们，则它们将失去效力。

底线：总比不记录问题要好，但是实际上您必须维护它们。

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

当您将“ TODO”视为评论的语义标签时，我认为它们确实有意义。

在我公司的编码标准中，我们指定负责开发人员的姓名缩写必须包含在TODO中（即，我将键入“ SAA TODO：”）。我认为这很有用，至少是作为一个约定，因为否则，存在将不合格代码留在TODO注释中以供将来的开发人员使用的诱惑。

有用的是，可以将许多IDE配置为将这些注释添加到任务列表中，从而可以对它们进行类似的处理以生成扭曲，并且不会无限期地将它们遗忘。

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

在德尔福：

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

以我的经验，TODO应该用来表明一段代码不可用，并告诉读者需要什么才能使它可用（本地或其他地方）。

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