[读书笔记] 代码整洁之道（一）

最近读完了马丁的clean code，颇有收获，简单整理下读书笔记，虽然整书是以Java代码做代码示例，但语言无国界，特别是编程语言更是如此，不管你从事的是以何种语言为主的开发环境，我相信，从本书中都会有所发现，有所收获。
全书总共17章，加上一个关于并发编程的附录，300多页的书，在面向程序员的书中，算不上厚。

第一章 整洁代码

本章主要是一个背景介绍和入门引导的作用，通过访问几个业界颇有建树的大师何谓整洁代码，给我们一个如何写出整洁代码的印象：“整洁代码只做一件事” “整洁代码深合你意“。。。从第二章开始从不同的方面分析整洁代码所需要具有的素质。

第二章 有意义的命名

本章最让我感到醍醐灌顶的内容是原来变量命名这个看似最无关紧要的部分，也包含如此多的学问，对于Windows平台的程序员来说，匈牙利命名法如数家珍，然而本章告诉我们，这是一种糟糕的命名方式，因为可读性太差，各种类型的缩写完全遮住了变量的原本面目，有时候一个很简单的变量，由于加上了很多类型前缀，导致天数一般的奇葩名字。
关于命名，个人觉得比较核心的几条规则：
1. 名副其实，不误导，有意义。例如：theList，theInfo，此类命名毫无意义，不具体，太过泛化。
2. 避免使用没有广泛流通的特定业务的名词缩写，例如我们在做一个图书管理系统（Library Management System），如果在某个类名字前面加上LMS…，我想除了本项目组的成员，没人能猜出LMS是什么意思（Love My Sister??）
3. 如果觉得一个命名不够好，那就重新命名，不要因为该名字使用地方过多，就望而祛步，主流的IDE都提供名字查找替换功能，只要稍加仔细，完全不用担心会有疏漏，而且这样做的好处可见一斑，绝对是值得的。

第三章 函数

几条务必要留意的准则：
1. 短小，单一职责。
个人认为这是对于函数最根本的一条原则（对于类也适用，但是类的单一职责是另外一个维度），几百行甚至上千行的函数，不用看也知道，肯定是包含了太多职责，这种函数太过臃肿，第20行声明的变量，第920行还在用，这种变量已经跟全局变量没有什么区别了。后期稍有更改的话，即便遵循开放封闭原则做扩展的话，也很难保证不出问题。函数应该做 一件事，做好这件事，只作这一件事。
2. switch-case过多。
当函数种出现过多的switch-case语句，就要提高警惕了，因为多半是函数设计出现了问题，因为，这意味着代码很长，其次，意味着函数不只做了一件事，这违反了单一职责原则，最后，它违反了开放封闭原则，每当添加新类型，代码就必须要修改。理想的做法是，适用工厂方法（设计模式中的工厂家族）封装变化，详细内容参见GOF的设计模式。
3. 关于函数参数。
首先，一个比较直观的是关于参数数量，函数参数最好不要超过三个，如果参数实在过多，应该将互相联系的参数封装为相应的类或者结构，如果参数与参数之间彼此不联系，那就说明该函数可以拆分。
要留心bool类型的参数，因为这样的参数往往表明，函数至少做了两件事（参数位true以及参数为false），职责不单一，这常常是函数需要拆分的信号。
最好不要用输出参数，即便是整个项目遵循特定的参数顺序规则，例如输出参数放在后面，但这样仍然无法让人容易的知道从哪里开始是输出参数，而且输出参数往往不够直观，特别是外人在阅读函数代码时。函数返回值才是函数的输出口，如果你的函数返回值过多，而且相关没有关联，同样的，你的函数该瘦身了。
4. 无副作用。
函数的副作用是指，函数调用时，某些暗藏的状态可能会被改变，例如：

int GetYourSalary()
{
...
    {
        ...
        m_yourBonus -= 1000;
        ...
    }
...
}

表明上，该函数是获取薪水，这是一件皆大欢喜的事情，可是谁知道它背后（嵌套很深）会偷偷的减少我们的年终奖金。。。好大一坨副作用。
5. 函数的结构化。
每个函数应该只有一个入口，一个出口，也就是减少return，break，continue，这些关键字往往会导致函数结构变得很复杂，许多意料之外的出口点，也就增加了bug存活的温床。对于goto，我只能说，还是不要用了吧，等有一天你面对眼花缭乱的代码，时不时冒出来一个goto时，那种草泥马奔腾的感觉，不提也罢。
6. 最后，正如第二章所说，一定要给函数起个好名字，性格决定命运，但名字影响一生啊。

稍后，会继续写之后的章节。