为什么注释掉代码然后逐渐将其删除以跟踪我已经完成的工作和尚待完成的工作是错误的？

每当我发现需要更改我的代码的很大一部分时，要么是因为它不正确，要么是因为需要将其修改为由于其他原因而需要进行的主要体系结构更改，这通常是我要做的：

1. 我注释掉了我怀疑可能需要更改的所有代码。我将注释掉的代码视为我的TODO列表。
2. 我逐步查看注释掉的代码并取消注释该代码的部分，或者将它们复制粘贴到其他位置，然后根据需要对其进行编辑，或者从头开始重写此代码的部分，查看注释掉的代码以供参考。每当我认为对部分注释掉的代码完成处理后，便将其删除。
3. 我继续进行此操作，直到看不到更多注释掉的代码为止。

我应该注意，我主要是在自己开发的个人项目上进行此操作。

但是，有人告诉我，我应该停止这样做。有人告诉我，我应该开始使用git，指代旧的提交以查看旧的代码，而不是留下注释掉的代码。有人告诉我：

注释掉代码是一个坏习惯，应该清除掉。您缺乏经验，因此无法理解。如果几年后您看到另一个喜欢注释代码的人的代码，您将开始对这个人发誓。每当我看到注释掉的代码时，我都将其完整删除，甚至根本不看它，因为通常这样的代码是完全不值钱的。您肯定不会看到在一个人的小型项目中注释掉代码的弊端。但是，如果您找到工作并保持这种习惯，那将是一种耻辱。

我想问一下我现在看不到的正在做的事情有哪些弊端吗？

我必须说我不太热衷于仅使用git查看过去的代码。如我所说，我将注释掉的代码视为待办事项列表。虽然git会向我展示代码的外观，但无法清楚地告诉我哪些代码部分仍需要检查以及哪些部分已经完成。我担心我可能会错过一部分代码并引入错误。

为了完整起见，我想补充一点，我要引用的人是一位经验丰富的开发人员，并且是Bob叔叔的“ Clean Code”的拥护者-Bob叔叔确实批评了他的书中严厉地注释掉了代码。

如果您最终删除了所有已注释掉的代码，那么我看不出任何真正的问题。将注释的代码留在代码库中是一种不好的做法，但是如果您全部研究并消除它，那不是您要做什么。我怀疑与您交谈的人不理解您正在使用的过程或教条主义。

实际上，注释的代码是无害的。问题是它很杂乱，难以阅读。罪恶要严重得多，但是要消除这很简单。作为注释代码的人，您可以确定可以完全删除该代码。

许多IDE和代码编辑器都在注释中了解某种“ TODO”语法。这是标记需要更改的替代方法。您可能需要考虑一下这一点，因为它提供了有关标记时的想法的更多信息。

归根结底，您可以通过各种方式为您带来最佳结果。即使这是一个团队项目，只要删除所有注释的代码，就不会给其他人带来负担。

我想问一下我现在看不到的正在做的事情有哪些弊端吗？

可以说，如果您一个人工作并且不使用版本控制并且认为可以这样做的话，那就没有办法了。

实际上，如果没有版本控制，在“时间”的任何时候做什么都没关系，因为代码始终是操作系统中“保存”当前文件的状态。

如果您使用版本控制，并且有大量注释作为“待办事项列表”，则可以修复其中一些并删除注释，然后重复，然后重复等等...然后保存“正在处理”代码和注释在您的修订历史中。如果您以后不再需要回滚到另一个提交甚至“樱桃采摘”，这将不是问题（例如，您在其中进行特定的提交并将其拉到另一个分支中使用）。但是，否则可能是一个问题。

可以说，这可以与硬盘软件“快照”相提并论，例如Windows。如果快照中包含病毒，则可以杀死该病毒，但随后需要回滚，则可以返回到该病毒再次存在的位置。

这种方法也有可能是一个问题，当你使用版本控制和工作与其他开发者，因为之后要看看你这有没有用他们的待办事项列表。实际上，这只是他们必须忽略和解决的混乱。在我们的团队中，我们总是删除所有注释，例如旧代码或“注释”。除非它们很有用-但这很少见，因为我们有“工作原理”的文档以及用于跟踪需要完成的事情的软件（也称为todo）。

另外，在处理较大的项目时，您倾向于协作，频繁提交和推送，因此如果他们正在将其分支合并到他们的分支中，则他们正在处理的分支可能会具有您的TODO列表。那么您的TODO清单就是每个人的事：D

总而言之，如果您不是一个人工作，尤其是在使用版本控制时，它会弄乱历史记录，并且可能会使其他开发人员感到混乱。

而且，在某些方面这是个人的事情，但是使用代码库作为“待办事项列表”并不是很理想。有一天，您可能会意外遗忘某些东西，或者忘记对它进行评论或错误地对其取消注释。

与采用许多架构，编码方法以及您个人或团队的工作方式一样，每种情况都可能需要不同的东西。因此，请考虑上述缺点以及使用版本控制的好处，并确定它是否对您有用。

听起来您的审稿人有点教条。我不确定发誓要注释掉代码的人是PC ;-)甚至是有用的;-)

但是更严重的是，我认为您的审稿人是对的，您应该认真考虑使用git（或其他一些源代码控制系统，但是git是明智的选择）。

这样可以减轻您注释掉代码的某些需求。

但是在我看来，在代码中包含一个TODO列表（无论是项目符号列表还是旧代码）-都是很合理的。但是您可能需要重新考虑如何做。一方面-我建议考虑其他人阅读您的代码。在您放弃并重新加入项目的一年后，其他人可能就是您。也可能完全是其他人。仅仅遇到注释掉的代码有点混乱。也许像：

/*
 * Need this sort of functionality added back before too long:
 * .... OLD CODE HERE
 */

就个人而言，我更倾向于这样的事情：

 * TODO:
 *      @todo   Possible get rid of intermediate LRUCache_ object.
 *
 *      @todo   Find some reasonable/simple way to get
 *              LRUCache<PHRShortcutSpec, PHRShortcutSpec, PHRShortcutSpecNoAuthCacheTraits_>   sRecentlyUsedCache (kMaxEltsInReceltlyUsedCache_);
 *              Working with ONE T argument
 *              Add(elt2cache).
 ...

而且我可以随意添加旧代码中的“代码段”，对您有所帮助。

使用git很难（很难）。这将需要您花费一些时间来学习，并且可能感觉它不属于您要实现的目标。但是，如果您要进行有益的编程，则需要作为团队的一部分并与团队进行交流，并且git就是当今的工作方式。一旦开始使用它，您会发现它非常有用的工具/拐杖，使您的软件开发更加轻松。

祝你好运！

注释掉代码有很多原因：

• 尚不正确，准​​备就绪后，您将不会对其进行注释。
• 您暂时将其注释掉以在调试时更改行为。
• 您不确定是否需要该代码，但是在测试了更多代码之前，不要删除它。
• 该软件的某些版本需要该代码，而本版本则不需要。
• 该代码已过时，但是花了很多时间才编写，并且您对它深有感触。此外，有一天可能会有用。

问题出在将代码放到床上，然后在几年后重新进行维护。您会发现代码库中散布着注释掉的代码。现在不再清楚为什么会有其中的任何一个，现在只是混乱。

如果您使用任何不错的版本控制工具，则可以放心删除不需要的任何代码，这是安全的，因为知道版本控制系统仍将其存储起来。版本之间的文件差异将显示已删除的内容。一旦实现了版本控制，唯一需要注释掉的就是临时性内容。如果您在实际上未使用的文件中找到注释掉的代码，则可以将其删除。

我不再重申为什么即使对于一个人的项目也应该使用源代码控制，因为那里还有很多其他资源可以告诉您执行此操作。但是，当前方法的一个主要相关缺点是，如果注释掉了代码，则将其从IDE中隐藏起来（如果您不使用IDE，则可能应该考虑使用它）。

例如，如果您想重命名方法或类，或更改方法采用的参数数量，您的IDE应该具有一个重构选项来执行此操作，它将找到所有适当的引用并进行相应的更新-但可能不会。搜索注释。

无需尝试猜测您需要在哪里进行更改，只需对它们进行更改，然后让您的IDE告诉您所做的更改已导致问题中断。然后，您可以以更外科的方式注释掉该代码，并希望在更短的时间里修复任何损坏的代码。

这是不好的，你应该停止。

原因归结为尝试一次性进行大量重构。

如果您注释掉大部分代码，请进行一些修复并检入，那么您已经检入了非功能代码。并且其他人认为的全部注释掉的东西都是陈旧的，可以忽略

如果您不经常检入，那么您正在积累合并冲突，而不是逐步记录进度。

您需要更改工作习惯，以便如果您必须中途停止，那么一切仍然可以进行。

采取婴儿步骤，并在每次之后检查以下各项：

• 提取接口
• 编写测试
• 重构功能

不要通过注释掉大块代码来将它们标记为“您的”，并让它们自己完成，直到它们完成或失败为止。

如果需要跟踪需要完成的工作，请使用scrum或trello等任务板