当前一篇 文章 被刊登在 dzone 上时 Jonathan Fisher 添加了一个相当有价值的评论:
我觉得在 “日志还是注释” 这个问题上你还应当写点别的，我认为日志就活注释，它可以用来解释程序的执行状态，同时提供产品中一部分有价值的信息。
这种情况我碰到过一次。有一个相当严格的代码环境强制要求写注释。他们要求你必须写详细注释，而且仅能写在接口上。如果你的代码或者测试用例不是足够易读的，那你就需要修改它们。
在这种要求下代码，想写注释的人很快就开始投向写日志的阵营。但在开始之前先让我们看看为什么。
通常说来是的。但当编程语言是汇编或者 FORTRAN 的时候例外。因为这些语言是用来执行而不是表达想法。今天的大部分语言更多的注重表达能力，能够比 FORTRAN 更容易的把想法转换成机器码。而且现在我们有了足够的内存和 CPU 来编译 JAVA、Groovy、Scala 之类的语言。如果当你在使用这些语言的时候你还是有写注释的欲望，那你应该思考下这两个问题：
如果你认为你确实不能把代码写的表达性更强一点了，因为这些业务逻辑太过复杂不能表达在代码中，请阅读文章代码文档的黄金原则并挑战一下。
注释是用来给维护你的代码的程序员读的。如果你要写的注释是在 Wiki 中可以查到的，那么就不要写出来分散别人的注意力了。
通常日志是有益的。但如果把日志当作一个更强大的注释来用，那就太没用在正地上了。永远不要这么干，一个不容忽视的事实可能不限于编程就是不要把一个工具用在设计之外的用途上。
你可能会害怕日志会降低系统性能。但就现在的日志库或者解决方案来说这还不足为虑。除非情况实在特殊，而且即使真的发生了，那么在第一次测试的时候调整它们。不要尝试过早的进行优化。
日志也应该具有易读性。因为它在系统中是独立的，和原本的业务逻辑是无关的，所以插入日志后可能会有降低可读性的危险。这点是你需要注意的。我的建议是不要使用字段或者变量来记录日志用到的字符串。日志文本只应该在记录的时候才出现。
插入日志语句要果决，不要犹豫。当你做代码评审的时候要考虑到日志有两条线 。一条线是阅读代码时的日志代码本身。另一条线是程序运行过程中的日志输出如何写入到文件的。 或许做一个包含产品和支持人员的日志评审也是一个很不错的实践。它可以和代码评审类似：阅读输出的日志并给出可读性 方面的反馈。我觉得这样很不错但没尝试过，如果有人尝试了，请告诉我。
最后：该用日志的时候用日志，该用注释的时候用注释。如果你想挖洞，就用铲子。要钉钉子，就用锤子。在任何时候使用合适的工具。
lzxz1234 02 July 2014