hexo使用畅言评论_为什么我们不使用评论

hexo使用畅言评论

1986年，我在布达佩斯工业大学学习PASCAL编程时，有一个专门为学生代码开发的预处理器。 如果内联注释的数量少于可执行代码的数量，它将停止编译过程。 有一个规则：我们必须至少有50％的代码有意义的注释。 30年过去了，现在我们与内联评论抗争。 干净的代码纯粹主义者宣扬根本没有内联注释，并且仅在界面上具有单元文档（如果是Java，则为JavaDoc）。 从代码本身来说，任何其他解释实现的内容都必须是自解释的。

那时甚至有一些工具可以将内嵌注释提取到文档中，其中部分包含可执行代码。 您还记得WEB和TANGLE吗？ 那时，有一种语言可以编译成TeX以用于文档编制目的，也可以编译成PASCAL以便执行代码，这似乎非常令人兴奋。 30年后，我们可以看到那是一条死胡同。 我们不会混合编程和文档。 我们宁愿将它们分开。

态度改变的原因是什么？ 30年前的计算机科学家是“愚蠢的”吗？ 他们是在提倡曾经是坏事吗？ 还是那个时候很好，现在很好呢？ 世界上是否发生了根本性的变化，我们生活在另一个世界中？

我最近在考虑这个问题，得出的结论是：两者都有。 “愚蠢”一词有些刺耳和粗鲁，但指出计算机科学家并不像今天那样了解那么多是可以接受的。 毕竟这是发展。 如果知识保持不变，那将意味着我们正处在30年前。 我们学到了很多与计算机科学有关的东西。 其中许多与人类科学有关，应属于心理学或类似领域。 那是菜的一面。

30年前要求发表评论。 今天，我们说，评论之所以不好是因为它们已经过时且具有误导性。 30年前的口头禅是使注释与代码保持一致并保持最新。 说起来容易，但人们往往不遵循该建议。 在一段时间内，您可以推动口头禅，也可以尝试强迫人们保持最新评论，但这与禁止青少年的性行为一样徒劳。 这就像在雨滴飘过头顶时，试图命令重力停止并走回家干一样。 人类的工作方式不同，您无法改变人类。 30年后，我们似乎学到了什么解决方案？ 使实践适应人类的能力和意愿。

如果评论过时且产生误导，那么最好不要发表任何评论。 另一方面，我们需要一些补偿所提供的功能注释丢失的方法。 我们现在的目标是可读代码。 这是规模的另一面。 这是世界上发生的变化。 我们拥有新的编程语言和新工具。 如果您需要在FORTRAN或COBOL中创建可读代码，从而无需内联注释，则可能会遇到麻烦。 因此，大力推动发表评论。 那些日子里，注释弥补了语言上的不足，并且包括误导性注释在内的平均结果要好于裸代码。

今天，我们有了Java，Scala，C＃，Go，Swift，Ruby，Python。 所有现代语言（抱歉，我错过了这些语言）都可以用不需要注释的可读且简洁的格式来表示行为和实现。 我们还使用单元测试，这在30年前是未知的，它比测试更能说明实现。 我们使用代码来记录文档，从瀑布到敏捷的文档越来越少。 我希望这是一个好的方向，我对未来充满好奇。

翻译自: https://www.javacodegeeks.com/2015/07/why-we-do-not-use-comments.html

hexo使用畅言评论