为了突出的考核结果

　　当管理者本身不懂代码，却有一套程序员“好坏”评价标准时，会出现什么情况?程序员要理清这套标准并不困难，因为他们的特长就是解决难题，然后他们会努力完善自己，从而迎合评价标准。代码行数、已解决Bug数量、注释的密度、代码深度等都可能是衡量编码人员的指标，但这些又都是相对标准，而不是绝对标准。也有些新颖的衡量手段(比如“已删除代码的行数”)。

　　为计算机编写

　　从某种意义上来说，所有的程序都是为计算机编写的，但计算机应当程序员最后才考虑的。计算机只注重语法，不注重注释和变量名称。大多数程序语言也不注重间距与代码格式化。当然，你还是要选择正确的算法，但不要想着通过微小的优化来加速算法。在for循环中，使用i++还是++i并不重要，编译器和JITs会解决这些问题。在考虑优化算法之前，还是应该先把代码写的清晰易懂。要知道编码在使用通用模式时，计算机和编译器运行的更快。

　　为了自己

　　虽然学习一门新的程序语言很有趣，不过如果你将整个公司架构都建立兴趣之上是不切实际的。Hacker News上曾有一则相关故事，LambdatheUltimate网站上还有更糟糕的案例。如果你是为自己写代码，你可以不加注释，可以随意使用糟糕的变量名，甚至使用其他“怪癖”，但这样写出来的怪异代码别人很难看明白。不过没关系，因为每个人都会时不时想在某些事上找点漏洞出来。

　　为后来者编程

　　编程是把抽象观念转换成计算机可以理解的形式。即使是细微的抽象观念，转换成代码也是很不简单。因此很多软件项目都衍生出了成千上万甚至是上百万行的代码，相当于一本代码书。通过有限的语法与其他人交流这些概念，大多数时候都注定失败。

　　我所写的最出色代码就是我愿意花时间来添加注释、列出代码流、甚至附上一些ASCII文字图的代码。编写过程专注于如何把自己抽象概念，与今后将有可能读到这些程序的、不幸的程序员进行传递和交流。我认为专注于这种交流，代码会变得越来越好，因为你会更深入地思考抽象概念以及如何对正在做的事情分层，而不是一味的编写代码和转到下一个程序块。

　　注释使代码变得更好理解。每当你再次做某事的时候，总会比上一次更好。当你在编写代码和注释时，就是将抽象概念向读者解释了两遍。这会迫使你思考更多。很多次我写完一个代码以后都会对它写一个注释。然后从头修订代码，甚至改变了一些小地方，例如选择更好的变量名称，来更好的交流想法。