究竟什么是优秀的代码？Robert Martin的一句话可以完美诠释。

代码质量的唯一衡量标准是每分钟说多少次WTF

我来解释一下这句话。当我在做code review时，通常会有三种不同的感受：

What-the-F**k (厌恶脸) — 这段代码并不是必要的
What-the-F**k (一脸钦佩) — 这家伙真聪明啊
What-the-F**k (愤怒值爆表) — 这什么垃圾玩意

所以当我们看代码时影响我们的第一印象的因素是什么呢？

这是一段整洁又漂亮的代码。
能够写出整洁又漂亮的代码是一个优秀工程师的标志。
It is Clean and Beautifully written code.
And writing clean and beautiful code is the mark of a GREAT softwarecraftsman.

要学会这项伟大的事业有两个关键点：知识和工作。
知识会教给你如何在变得更加专业的模式、原则、实践和启发式的方法。但这些知识需要你通过大量的读写、不断的实践和努力才能获得。
简而言之，学会如何写整洁的代码并非一件简单的事。你必须要为之付出努力，必须一次又一次的练习、发现问题、经历失败，直到正确处理为止。这一过程没有任何捷径。
下面我将向你介绍一些如何写出整洁且漂亮的代码的技巧。
“What is in a NAME”
Kendrick Lamar说过：

如果我要讲一个真实的故事，那么一定是从故事的命名开始。
If I’m gonna tell a real story, I’m gonna start with my name

命名会遍布代码的每一个角落，我们会为函数、类、参数、包等命名，还会为源文件、目录命名。总之，在写代码的过程中，好的命名可能是使代码变整洁的最重要的因素。
你的命名应该显示出你的意图。选择一个好的名称会耗费你的一些时间，但是如果随意命名，以后你会浪费更多的时间来理解它。所以请尽可能使你的命名更加合理，读你的代码的人也会因此感谢你。
你要谨记的是，变量、函数和类的命名应该能回答三个问题：它为什么存在、它是做什么的、它用在哪里。
这不仅需要良好的描述能力，还需要了解跨国界的文化背景。要教会你这些，没有人能比你自己更合适了。
“Functions should DO ONLY ONE THING.”
我们所说的「单一责任」原则。
Louis Sullivan对此有过完美的描述

形式跟随函数
Form follows function.

每个系统都是由特定的编程语言构建而成。函数通常是动词，而类通常是名词。函数任何编程语言中通常都是出现在第一行，写出整洁代码的本质其实就是写出整洁的函数。
要想写出整洁的函数，首先应该遵循两条黄金法则：

函数应该尽可能短小
函数应该只做一件事

这意味着你的函数不应该出现嵌套的结构。所以函数的缩进级别不应该大于一个或两个，这会让你的代码更容易阅读、理解和消化。除此之外，我们还需要确保函数中的语句都处于同一抽象级别。
在一个函数中如果混有不同的抽象级别通常会使代码变得十分混乱，并且难以管理。优秀的工程师会把函数当作给别人讲的一段故事，而不只是编码。
他们通常使用所选编程语言的功能来构建更加丰富、更具表现力和更加简洁的代码块。这使他们成为更好的“故事讲述者”。
“Comments do not make up for bad code”
Venus Williams为我们敲响警钟：

每个人都有自己的注释，这是谣言的开始。
Everyone makes their own comments. That’s how rumors get started.

注释是一把双刃剑，在正确的位置添加注释可以为他人提供最有用的帮助。另一方面，浪费空间来添加无用的注释会使代码更加的混乱。如果注释提供了错误的信息，那对代码来说可以说是一种灾难了。
总之，注释是一种不可缺少的恶魔。为什么呢？通常，代码的注释越旧，维护起来就越困难。很多程序员因为修改代码时不维护注释而臭名昭著。
随着代码的发展，代码做出了许多改动，但注释并没有随之修改，这是一个很大的问题。
请铭记，带有少量注释的简洁代码远胜于带有大量注释的混乱代码。不要浪费时间来解释你制造的混乱，而是要花些时间来清理这些混乱。
“Formatting Code is always a priority”
Robert C. Martin说过

代码格式与沟通有关，而沟通是专业开发人员的首要任务。
Code formatting is about communication, and communication is the professional developer’s first order of business.

上面的说法可能不被大家认可，但这是一个优秀的开发人员的最重要的品质。格式化的代码是你心灵的窗户，我们希望人们对我们的秩序、对细节的关注和思想的清晰印象深刻。当他人看代码时，如果看到的是混乱的、开头结尾不清晰的代码块，这会直接损害我们的声誉，这一点毋庸置疑！
如果你认为代码“可以使用”是专业程序员的第一要务，那么你不会有很好的发展的。你今天的功能很有可能在下个版本进行更改，但代码的可读性是不会改变的。
当原始代码已经改的面目全非时，代码的风格和可读性将影响代码的可维护性。
以后，你会因为自己的代码风格和纪律被人们记住，而不会因为某段代码。因此，你需要注意你的代码格式，使它受到简单的规则约束，这样的规则必须是所有团队成员都能理解的。
Write your “try-catch-finally” statement first
Georges Canguilhem明确提到：

人类都会犯错误，但是坚持错误的却是恶魔。
To err is human, to persist in error is diabolical.

错误处理是每个程序员都必须要做的事情，输入可能异常，设备也可能故障。作为开发人员，我们希望程序按照我们的预期来执行。然而，问题不是处理错误，而是清晰易读的错误处理方式。
很多代码以处理错误为主，导致主代码逻辑被淹没在其中。这种做法是完全错误的。代码应该整洁、健壮，并且以一种优雅的方式处理错误，这也是优秀工程师的一种标志。
其中一个错误处理方法是通过适当的try-catch代码块来捕获所有错误。在执行try-catch-finally中try部分的代码时，任何时间发生异常，都会进入catch部分执行。
因此，在代码中使用try-catch-finally可能是一种比较好的选择。它能帮助你在try部分定义你希望执行的代码，而不用去担心代码出错时怎么办。
你抛出的每一个异常都应该具有完整的上下文以确定错误的来源和位置。具有创造性的错误信息会在代码写出来后很久，甚至是作者已经离开很长时间后仍然被人们记住。
Bringing it all together
那么如何综合一下上面提到的技巧呢？

答案是代码意识，是软件工程中的一种常识。
The answer is code-sense; the software equivalent of common sense.

据Robert Martin所说，”编写整洁的代码需要通过一段痛苦的过程来获得一些小技巧，这些小技巧被称为代码意识“。有些人天生就有这种感觉，而有些人则需要通过实践、坚持不懈和毅力来获取它。这种意识不仅仅是帮助我们区分好代码和坏代码，更能够给我们代码将坏代码转换成好代码的能力。
代码意识可以帮助开发者们选择最好的工具来指导他们创造出更有价值的整洁又漂亮的代码。
简而言之，具有代码意识到程序员就像是画家，他可以将一块空白的屏幕变成精美的艺术品，并被人们记住很长时间。
就像Harold Abelson所说的一样：

代码写出来首先是给人读的，然后才是指导机器要怎么做。

References
“A handbook of Agile Software Craftsmanship” — Robert Martin.
“A handbook of Agile estimation” — Mike Cohn
原文地址
https://medium.com/swlh/excellent-code-clean-and-beautiful-code-b541ca4b5a39
译者点评
这位作者以一种比较激进的语言告诉大家要注意代码的可读性，不过大家的观点都很类似，无非就是命名、代码格式、注释和错误处理这些点。希望这篇有些激进的文章可以帮助到一些同学，减少别人在review你的代码时，使用WTF的次数。

http://harttle.com/2015/04/13/elegant-and-bad.html



可持续开发不仅在于项目架构设计，还与代码质量密切相关，代码的整洁度和质量成正比。—— Robert C. Martin, “Clean Code”



如果你还没有发现代码质量的区别，如果你从未见过优秀的代码，或者从未见过糟糕的代码，那么本文将以直观地对比，告诉你代码质量究竟会有多大的区别。

代码量

我们知道代码量显示着功能的复杂程度，例如Windows XP的代码量超过2000万行，Linux内核有1500万行（2012年）。然而代码量和功能数量之间并非线性关系。

优秀的设计中，代码量和功能数的关系是这样的：



糟糕的设计中，代码量和功能数的关系是这样的：



优秀的系统往往会有优秀的结构设计：层次清晰、职责单一、模块化，方便扩展或者复用。功能的添加往往只是在现有框架中添加少量代码。

然而糟糕的设计中，层次混乱、互相耦合、难以阅读，既难以复用又不易扩展。每当被要求添加功能时，不得不几乎完整地实现整个功能的流程，并修复与原系统的所有兼容问题。

注释

优秀的代码中，注释是这样的：



糟糕的代码中，注释是这样的：



最愚蠢的程序员都能写出机器能读懂的代码，而优秀的程序员能写出人可以读懂的代码。


程序的注释是为了让人读得懂。多数优秀的代码中，注释几乎接近代码行数的一半，描述函数功能、解释参数配置、指出陷阱所在。而糟糕的代码中不仅不含这些注释，甚至会保留大量残余代码，可读性差又难以重构。

命名

优秀的代码中，命名是这样的：



糟糕的代码中，命名是这样的：



命名是为了让代码更加容易阅读，使用规范的术语不仅更加易懂，同时也是开发者知识水平和开发经验的表现。如果说以中文拼音命名显得奇怪，那么直接以a, b, c, d命名的便会显得可恨，谁记得你的a是神马东西！

冗余

看一个经典的例子，字符串替换：



稍微有点Javascript常识的便会想到正则表达式：



何必拷贝这一堆的代码给老板看呢？开发中确实有很多时候，直接拷贝代码既能立竿见影地完成功能，又不会影响原有功能。但这样的代码多起来之后，万一功能调整你便需要重新debug所有的副本。花一些时间学习更优雅的用法是值得的。

函数

保持函数的短小，使你的代码更加易读，例如：



将复杂的逻辑分步骤完成。如果写在一起将会是这样的：



相信我，一旦你写了这样的函数，它会随着时间的推移变得越来越长，直到有一天，你也忘了其中的一段代码到底是做什么的。

事实上，复杂的函数不仅可以按照步骤划分，更应按照层次来细化。不要在一个函数中进行不同层次的操作，否则它会变得非常难懂。

如果你还没有发现代码质量的区别，如果你从未见过优秀的代码，或者从未见过糟糕的代码，那么本文将以直观地对比，告诉你代码质量究竟会有多大的区别。








[  代码量  ]








我们知道代码量显示着功能的复杂程度，例如Windows XP的代码量超过2000万行，Linux内核有1500万行（2012年）。然而代码量和功能数量之间并非线性关系。




优秀的设计中，代码量和功能数的关系是这样的：









糟糕的设计中，代码量和功能数的关系是这样的：









优秀的系统往往会有优秀的结构设计：层次清晰、职责单一、模块化，方便扩展或者复用。功能的添加往往只是在现有框架中添加少量代码。

然而糟糕的设计中，层次混乱、互相耦合、难以阅读，既难以复用又不易扩展。每当被要求添加功能时，不得不几乎完整地实现整个功能的流程，并修复与原系统的所有兼容问题。










[  注释  ]








优秀的代码中，注释是这样的：









糟糕的代码中，注释是这样的：







最愚蠢的程序员都能写出机器能读懂的代码，而优秀的程序员能写出人可以读懂的代码。


程序的注释是为了让人读得懂。多数优秀的代码中，注释几乎接近代码行数的一半，描述函数功能、解释参数配置、指出陷阱所在。而糟糕的代码中不仅不含这些注释，甚至会保留大量残余代码，可读性差又难以重构。










[  命名  ]








优秀的代码中，命名是这样的：









糟糕的代码中，命名是这样的：






命名是为了让代码更加容易阅读，使用规范的术语不仅更加易懂，同时也是开发者知识水平和开发经验的表现。如果说以中文拼音命名显得奇怪，那么直接以a, b, c, d命名的便会显得可恨，谁记得你的a是神马东西！





看一个经典的例子，字符串替换：









稍微有点Javascript常识的便会想到正则表达式：









何必拷贝这一堆的代码给老板看呢？开发中确实有很多时候，直接拷贝代码既能立竿见影地完成功能，又不会影响原有功能。但这样的代码多起来之后，万一功能调整你便需要重新debug所有的副本。花一些时间学习更优雅的用法是值得的。










[  函数  ]









保持函数的短小，使你的代码更加易读，例如：









将复杂的逻辑分步骤完成。如果写在一起将会是这样的：









相信我，一旦你写了这样的函数，它会随着时间的推移变得越来越长，直到有一天，你也忘了其中的一段代码到底是做什么的。





事实上，复杂的函数不仅可以按照步骤划分，更应按照层次来细化。不要在一个函数中进行不同层次的操作，否则它会变得非常难懂。



文章来源:猿份


编辑 | 神经码


图片源于网络，版权归原作者所

        作为程序员，写代码是需要一种崇高无上的精神来支撑的，写出优秀的代码，更需要你有深厚的底蕴和良好的编码习惯。我们先来探讨一下什么样的代码才是优秀的代码。
1、稳定可靠（Robustness）

2、可维护且简洁（Maintainable and Simple Code）

3、高效（Fast）

4、简短（Small）

5、共享性（Reusable）

6、可测试性（Testable）

7、可移植性（Portable）

面对以上的目标，我们总结了以下10个写代码的技巧，希望对你有所帮助。

1、百家之长归我所有（站到巨人的肩膀上）

       其实写代码的方式有很多，每个人都有自己的风格，但是众多的风格中总有一些共性的、基本的写代码的风格，如为程序写注释、代码对齐等等。是不是编程规范？对就是编程规范。


2、取个好名字（有意义）

       取个好的函数名、变量名，最好按照一定的规则起名。还是编程规范。


3、凌波微步，未必摔跤

       这里我用“凌波微步”来形容goto语句。通常，goto语句使程序跳来跳去，不容易读，而且不能优化，但是在某种情况下，goto语句反而可以增强程序的可读性。Just go ahead，not go back。


4、先发制人，后发制于人

       Defensive Coding指一些可能会出错的情况，如变量的初始化等，要考虑到出现错误情况下的处理策略。测试时要多运行几个线程。有些程序在一个线城下运行是正常的，但是在多个线程并行运行时就会出现问题；而有些程序在一个CPU运行几个线程是正常的，但是在多个CPU下运行时就会出现问题，因为单CPU运行线程只是狭义的并行，多CPU一起运行程序，才是真正的并行运算。


5、见招拆招，滴水不漏

       这里的Error Case（错误情况），是指那些不易重视的错误。如果不对Error Case进行处理，程序在多数情况下不会出错，但是一旦出现异常，程序就会崩溃。


6、熟习剑法刀术，所向无敌（没事的时候多看API）

       用“剑法刀术”来形容一些API是因为它们都是经过了很多优秀开发人员的不断开发、测试，其效率很高，而且简洁易懂，希望大家能掌握它，熟悉它，使用它。是不是象我们的ULIB。


7、双手互搏，无坚不摧

       这里的测试不是指别人来测试你的代码，而是指自己去测试。因为你是写代码的原作者，对代码的了解最深，别人不可能比你更了解，所以你自己在测试时，可以很好地去测试哪些边界条件，以及一些意向不到的情况。


8、活用断言

       断言（assertion）是个很好的调试工具和方法，希望大家能多用断言，但是并不是所有的情况下都可以用到断言。有些情况使用断言反而不合适。


9、草木皆兵，不可大意

       是指在写代码时，要小心一些输入的情况，比如输入文件、TCP的sockets、函数的参数等等，不要认为使用我们的API的用户都知道什么是正确的、什么是错的，也就是说一定要考虑到对外接口的出错处理问题。


10、最高境界，无招胜有招

       意思就是说尽量避免写太多的代码，写的越多，出错的机会也越多。最好能重用别人开放的接口函数或直接调用别人的api。



本文链接：http://www.apkbus.com/android-11386-1.html