怎样写出较好的代码

这时老生常谈的话题了，写写自己的一点体会，防止以后我忘记了。

有好多条，尽量按照重要顺序排列。

0：起个好名字

为啥这个放第一？其实有很多东西看起来比这个更重要，比如要牢记语法、熟练掌握常用算法、正确的分析好逻辑、画出各种图。。。。。。

我想原因至少包括以下一些：

//写代码的时候，取名字是最常做的一件事儿。完整的代码由很多部分组成，其实，名字就是用来标识这些不同部分的。你需要给代码段、函数、变量、类、对象等等各种东西取名字。这些名字帮助作者，也帮助读者分析、记住这些不同的部分。也许，只有为这个世界上多数人认为已知最早的计算机编程的人才不需要这一点。不过，我想，他们肯定有其它的办法，比如，把不同功能的穿孔卡片分类放在几十个有名字的小抽屉里等等。或者干脆雇很多人。另一个例子是，为什么用各种刁钻的办法修改各种名字是混淆器是用的基本把戏之一。

//真正有用的代码会长期生存下去，必然有很多人接触它、修改它、使用它，这时，有好的名字，会让大家更容易理解，花费更少的时间作对事情。有很多人懒得去分析已有的代码，我想肯定有一种原因是：那些代码本身难以分析，不管是什么原因。当获得了代码块的正确接口以后，也许重新写一个会更好。当然，这并不是最好的主义。因为，也许有些时候看起来非常明显的接口却不像它的表面看起来那么简单。特别是在其中发现了某些奇怪的代码，类似于一本书的第十位收藏者在旁边增加的眉批之类，就尤其值得注意了。也许失去它，某天你就必须面对某种CPU、某个蹩脚的软件、一个带有bug的编译器或其它什么鬼东西给你甩下的烂摊子。所以，起个好名字，让其他人更容易分析你的代码。

最后的问题是：怎样起个好名字？

答案很简单：编码规范中。但可惜的是，可能很多人更关注的是诸如每个函数有多少行代码、函数内部的TAB代表几个空格、大括号要放在行首或者行尾之类的部分，而不太去关心如何真正起个好名字。我想每种语言都有自己的编码规范，虽然大部分流行的高级编程语言的编码规范看起来都差不多，至少其中关于命名的部分是如此。其实最重要的就是：明确，不要用容易让人产生歧义、混淆的名字。比如“_____"和”______"的问题就在于它们看起来差不多。在这一点上，“boolean isMan＝false；”应该能算最好的证明了。另外，可能在英语命名中不要是用带有时态的单词也算一个吧。我想被中学英语课本中的时态练习弄死超过一次的人肯定会同意。

3：少做事儿

很显然，项目经理和公司老板肯定不会对你这么说。当然，意思也不一样。这里指让一段代码“少做事儿”。让一个代码块、一个类短一点、简单点儿、功能少一点。从基本原理上讲，设计软件产品的过程与传统行业设计产品的过程大概是相同的。都是首先有一个基本的目标，然后对问题域进行分解，将复杂的问题分解为较简单的问题来解决。可以想象，问题将会被分解到足够小，以便咱们一眼就可以看到解决的办法而且还不出错。这时候，就已经是“足够短、足够简单、功能足够少”了。

那么，怎么做到？答案其实很简单，看看一段代码、一个方法有多长。一般情况下，如果很长，比如已经超过100行了，可以考虑继续分解。少做事儿有很多好处，比如容易测试、容易实现松耦合等等，这些自不待言了。

5：单元测试

这里谈的问题和QC无关，而只关注于”习惯“。只要不懒，每个程序员都能做好单元测试，至少针对自己的代码。有很多人说没时间做单元测试，或者公司、项目经理等等不给安排时间做单元测试。但我想不会不给安排除bug的时间吧。谁这样干，他就是在开玩笑。现在的自动单元测试工具非常多，易学易用，当它跑起来的时候让人感到心情舒畅，而且更让你心里有底。另一个原因在于，这种测试几乎不用花费任何成本。很容易想象，在工厂中要测试一种新的加工工艺，试制一种新零件需要多少钱和时间。这一点，也是软件工程和传统工程之间一个很大的差别。

10：松耦合

可能很多人会想到“解耦合”，其实，从根子上讲这办不到，当然，有点儿“咬文嚼字”。原因在于写代码的目的是为了解决特定问题，这其中必然执行某种特定逻辑，只要这种逻辑不消除，就无法真正“解耦合”。好吧，也许在某个局部，能在一定程度上”解耦合“。大体上讲，怎样实现”松耦合“，一个简单的方法是”写较短的、功能较单一的代码“。不要指望用一段代码搞定一切，不要让它干太多事儿，有太多逻辑等等。想像一下牦牛的尾巴，虽然牦牛尾巴上的每一根毛确实都是独立的，但没法把它分出来，它们全搅和到一起了！如果强行扯出来一根，可能会把其它的弄断。最后说一句，如果一个函数、方法、有明确意义的代码块的长度超过了美国的《独立宣言》中头尾的长度（中间一直在控诉英国殖民者的暴行，如果当时不搂着，还能写更长），那么，可以尝试分成两份。