B轮融资|代码注释的艺术，优秀代码真的不需要注释吗？( 二 ) 芯片|创投圈

代码优于注释
\"Comments Do Not Make Up for Bad Code\" -- Robert C.Martin 《Clean Code》译：注释不能美化糟糕的代码
当需要为一段代码加上注释时，说明代码已经不能很好的表达意图，于是大家开始为这段代码添加注释。 Robert C.Martin在 Clean Code 中提出一个观点：注释不能美化糟糕的代码。能用代码表达的直接用代码表达，不能用代码表达的，你再想想，如何能用代码表达。复杂的代码最直接的表现就是不够直观、难以理解，加上注释后往往会清晰很多，但你是愿意看这段代码
// 判断是否活跃用户if((customer.getLastLoginTime().after(dateUtils.minusDays(new Date()15))customer.getCommentsLast30Days()5) || orderService.countRecentDaysByCustomer(customer30)1) 还是这段代码？
if(customer.isActive()) 糟糕代码的存在，通常是我们写注释的常见动机之一。这种试图粉饰可读性差的代码的注释称之为『拐杖式注释』，即使大名鼎鼎的JDK ，也存在这样的拐杖式注释。
public synchronized void setFormatter(Formatter newFormatter) { checkPermission(); // Check for a null pointer newFormatter.getClass(); formatter = newFormatter; 这是取自JDK java.util.logging.Handler类的setFormatter方法，作者为了不让空指针异常下传，提前做一次空指针检查。没有这段注释我们完全不知道游离的这句 newFormatter.getClass() 到底要做什么，这段注释也充分表达了作者自己也知道这句代码难以理解，所以他加上了注释进行说明。但我们完全可以用 Objects.requireNonNull() 来进行替代。同样的代码作用，但可读性可理解性大不一样， JDK里的这段代码，确实让人遗憾。
注释否定论
\"If our programming languages were expressive enough or if we had the talent to subtly wield those languages to express our intent we would not need comments very much—perhaps not at all.\" -- Robert C.Martin 《Clean Code》译：若编程语言足够有表达力，或者我们长于用这些语言来表达意图，就不那么需要注释--也许根本不需要
通过代码进行阐述，是注释否定论的核心思想。当你花功夫来想如何写注释，让这段代码更好的表达含义时，我们更应该重构它，通过代码来解释我们的意图。每一次注释的编写，都是对我们代码表达能力上的差评，提升我们的归纳、表达、解释能力，更优于通过注释来解决问题。当代码足够优秀时，注释则是非必须的。并且需求在不断调整，代码一定会随之变动，但注释可能慢慢被人遗忘，当代码与注释不匹配时，将是更大的灾难。
软件设计的乌托邦曾经我的确对优秀的代码不断钻研，对代码本身所蕴含的能量无比坚信。如同当科学代替鬼神论走上历史舞台时，即使存在有科学解释不了，我们依然坚信只是科学还需要发展。当代码别人无法理解时，我会认为是我表述不够精准，抽象不够合理，然后去重构去完善。有一次给老板review代码，当时老板提出， “你的代码缺缺少注释” ，我说不需要注释，代码就能自解释。于是老板现场读了一段代码， “query-customer-list 查询客户”、“transfer-customer-to-sales 分发客户到销售”、“check-sales-capacity 检查销售库容” ，每一个类每一个函数，一个单词一个单词往外蹦时，你会发现好像确实都能读懂，于是老板回了一个“好吧” 。
美丽的乌托邦
\"'good code is self-documenting' is a delicious myth\" -- John Ousterhout《A Philosophy of Software Design》译：‘好的代码自解释’是一个美丽的谎言
在软件设计中，总有一些软件工程师所坚信的诗和远方，有的是大洋彼岸的美好国度，有的或许是虚无缥缈的理想乌托邦。 John Ousterhout教授在 A Philosophy of Software Design 中提到一个观念， ‘好的代码自解释’是一个美丽的谎言。我们可以通过选择更好的变量名，更准确的类与方法，更合理的继承与派生来减少注释，但尽快如此，我们还是有非常多的信息无法直接通过代码来表达。这里的信息，或许不单单只是业务逻辑与技术设计，可能还包括了我们的观感，我们的体验，我们的接纳程度以及第一印象带来的首因效应。