1.摘要

这是烂代码系列的第二篇，在文章中我会跟各人接头一下如何尽大概高效和客观的评价代码的黑白。

在宣布了关于烂代码的那些事（上）之后，发明这篇文章竟然意外的很受接待，许多人也描(tu)述(cao)了各自代码中这样可能那样的问题。

最近部分在组织bootcamp，正好我认真培训代码质量部门，在培训课程中让各人花了不少时间去接头、改造、完善本身的代码。固然刚结业的同学对付代码质量都很用心，但最终泛起出来的质量仍然没能到达“十分优秀”的水平。 究其原因，主要是不相识好的代码“应该”是什么样的。

2.什么是好代码

写代码的第一步是领略什么是好代码。在筹备bootcamp的课程的时候，我就为这个问题犯了难，我实验着用一些准确的界说区分出“优等品”、“良品”、“不良品”；可是在总结的进程中，关于“什么是好代码”的描写却大多没有可操纵性

2.1.好代码的界说

随便从网上搜索了一下“优雅的代码”，找到了下面这样的界说:

Bjarne Stroustrup，C++之父：

Grady Booch，《面向工具阐明与设计》作者：

Michael Feathers，《修改代码的艺术》作者：

看起来好像说的都很有原理，但是实际评判的时候却难以参考，尤其是对付新人来说，如何领略“简朴的、直接的代码”可能“没有明明的需要改进的处所”？

而实践进程中，许多同学也确实面临这种问题：对本身的代码老是处在一种心里不踏实的状态，可能是本身以为很好了，可是却被其他人认为很烂，甚至有屡次我和新同学因为代码质量的尺度一毗连头好几天，却谁也说服不了谁：我们都僵持本身对付好代码的尺度才是正确的。

在经验了无数次code review之后，我以为这张图好像总结的更好一些：

代码质量的评价尺度某种意义上有点雷同于文学作品，好比对小说的质量的评价主要来自于它的读者，由个别主观评价形成一个相对客观的评价。并不是依靠字数，可能作者利用了哪些修辞手法之类的看似完全客观但实际没有什么意义的评价手段。

但代码和小说尚有些纷歧样，软件开发，它实际存在两个读者：计较机和措施员。就像上篇文章里说的，纵然所有措施员都看不懂这段代码，它也是可以被计较机领略并运行的。

所以对付代码质量的界说我需要于从两个维度阐明：主观的，被人类领略的部门；尚有客观的，在计较机里运行的状况。

既然存在主观部门，那么就会存在个别差别，对付同一段代码评价会因为看代码的人的程度差异而得出纷歧样的结论，这也是大大都新人面临的问题：他们没有一个可以执行的评价尺度，所以写出来的代码质量也很难提高。

有些先容代码质量的文章报告的都是倾向可能原则，固然说的很对，可是实际指导浸染不大。所以在这篇文章里我但愿尽大概把评价代码的尺度用（我自认为）与实际程度无关的评价方法暗示出来。

2.2.可读的代码

在衡量好久之后，我抉择把可读性的优先级排在前面：一个措施员更但愿接办一个有bug可是看的懂的工程，照旧一个没bug可是看不懂的工程？假如是后者，可以直接关掉这个网页，去做些对你来说更有意义的工作。

2.2.1.逐字翻译

在许多跟代码质量有关的书里都强调了一个概念：措施首先是给人看的，其次才是能被呆板执行，我也较量认同这个概念。在评价一段代码能不能让人看懂的时候，软件开发，我习惯让作者把这段代码逐字翻译成中文，试着构成句子，之后把中文句子读给另一小我私家没有看过这段代码的人听，假如另一小我私家能听懂，那么这段代码的可读性根基就及格了。

用这种判定方法的原因很简朴：其他人在领略一段代码的时候就是这么做的。阅读代码的人会一个词一个词的阅读，揣度这句话的意思，假如仅靠句子无法领略，那么就需要接洽上下文领略这句代码，假如简朴的接洽上下文也领略不了，大概还要把握更多其它部门的细节来辅佐揣度。大部门环境下，领略一句代码在做什么需要接洽的上下文越多，意味着代码的质量越差。