我的任务是(几乎)消除代码注释

最近我开始注意到，我编写的大多数注释要么是多余的，要么是代码中其他失败的借口。

自从意识到这一点以来，我一直在有意识地努力从我编写的代码中删除大部分注释。

我发现评论大体上可以归入几个常见的类别。以下是我一直以来处理每一个问题的方式：

我经常发现自己使用注释，而将代码提取到方法会更好。

现在我不需要了解免费送货是如何应用的，只需要了解它是在满足这个条件时应用的。

第一行合并了两个关注点；付款是否到期，以及付款到期时该怎么办。

将谓词移入具有适当名称的新变量中，可使代码更易于阅读，并消除对注释的需要：

注意：我甚至可以在这里更进一步，将谓词封装在Order对象中：order.PaymentDue。

当我声明一个变量，然后稍后使用它时，这种情况最常见。

如果该变量命名不当，我会本能地写一条注释，解释使用它的代码在做什么。

注意：当然，声明和使用变量之间差距不大的较短函数也会有所帮助。

我通常在编写脑海中尚未完全成形的代码时添加这些注释。

我知道我需要代码做什么，所以我编写完成工作的第一件事。

这类代码通常伴随着一个注释，该注释解释代码做什么，而不是解释它为什么这样做。

我应该做的是返回并重构代码，使其自文档化，使注释变得不必要。

有时候，我会读到我前段时间写的代码，不知道为什么会写得这么奇怪。

通常，这是因为我对它进行了分析，发现它的速度要快得多，或者因为它捕捉到了一种边缘情况，而做同样事情的更直观的方法可能无法做到这一点：

//进行性能分析时，运行两个单独的查询并将结果合并到内存中//比在SQLvar USERS=sql中执行连接快2倍。GetUsers()；var task=sql。GetAllTasks()；.。等等。

我写的大多数评论都出自懒惰的编码，可以通过简单地命名更好的东西或添加更多的抽象来消除。

我发现，当我专注于删除代码中的大部分注释时，它实际上变得更具可读性。例外的是解释原因的评论，而不是如何解释的评论。