代码整洁之道(一)

　　这本书作为一个初级的程序员和想进入这个行业的人来讲，很值得一读，本人尚未读完，程序员的写代码素质有待提高...

阅读进度：

第一章　　整洁代码

第二章　　有意义的命名

第三章　　函数

第四章　　注释

第五章　　格式

第六章　　对象和数据结构

第七章　　错误处理

第十章　　类

 

序：

<1>软件质量，不但依赖于架构和项目管理，而且与代码质量紧密相关;

<2>代码质量与其整洁度成正比。干净的代码，既在质量上可靠，也为后期维护、升级奠定了良好的基础;

<3>” 小处诚实非小事”，“神在细节之中”;

<4>“5S”哲学：整理、整顿、清楚、清洁、身美；

 

第一章       整洁代码

(1.1)要有代码

       我们永远抛不掉代码，代码呈现了需求的细节，将需求明确到机器可以执行的细节程度，就是编程要做的事情；我们无法抛弃必要的精确性，所以代码永存;

(1.2)糟糕的代码

       勒布朗法则：稍后等于永不；要及时清理自己的代码，不要让糟糕的代码毁了自己的事业和公司;

(1.3)混乱的代价

       *拖缓团队的生产力，引发各种矛盾;

       <1.3.4>整洁代码的艺术

                 写整洁代码，需要遵循大量的小技巧，贯彻刻苦习得的“整洁感”。这种代码感就是关键所在;

       <1.3.5>什么是整洁代码

               Bjarne Stroustrup:

                

               Grady Booch:

 　　　　　

               Dave Thomas:

 　　　　　

              Michael Feather:

 　　　　  

　　　　　  Ron Jeffries:

 　　　　 

 　

　　

　　　　　Ward Cunningham

          

 

(1.4)思想流派

       要习百家之长，自成一家

(1.5)我们是作者

       <1.5.1>下次你写代码的时候，记得自己是作者，要为批判你工作的读者写代码;

       <1.5.2>读与写(代码)话费时间的比例超过10:1，写新代码时，我们一直在阅读旧代码;

       <1.5.3>要想干的快，想轻松写代码，先让代码易读吧，即便那会使得编写过程更难;

(1.6)童子军军规

       把代码写好可不够，要时时保持代码整洁，不要让代码随时间的流逝而腐坏,记得每次签入时，代码要比签出时要干净;

(1.7)前传与原则

       单一职责原则(SRP):

       开发闭合原则(OCP):

       依赖倒置原则(DIP):

 

 

第二章       有意义的命名

(2.1)介绍

       软件中随处可见命名。变量、函数、参数、类、封包、源代码以及源代码所在目录、文件

(2.2)名副其实

       变量、函数或类的名称应该已经答复了所有的大问题。它告诉你，它为什么会存在，它做什么事，应该怎么用。如果名称需要注释来补充，那就不算是名副其实;

(2.3)避免误导

       必须避免留下隐藏代码本意的错误线索，避免使用与本意相悖的词语。提防使用不同之处较小的名称;

(2.4)做有意义的区分

       如果程序员只是为了满足编译器或者解释器的需要而写代码，就会制造麻烦;

       例如:以数字系列命名(a1,a2,a3..)。

　　   另外，同一个意思用了不同的名字，废话是另一种没有意义 的区分；

　　   要区分名称，要有读者能鉴别不同之处的方式来区分;

(2.5)使用读的出来的名称

       Eg:genymdhms(差) PK generationTimestamp(好)

(2.6)使用可搜索的名称

       单个字母名称和数字常量有个问题，就是很难在一大篇文字中找出来;

       长名称胜于短名称，搜的到的名称胜于用自造编码写就的名称;

(2.7)避免使用编码

       <2.7.1>对于匈牙利语标记法(使用见仁见智吧)

              <2.7.1.1>Windows的C语言时代，编译器不做类型检查，程序员需要匈牙利语标标记法来帮助自己记住类型;

              <2.7.1.2>现代编程语言具有丰富的类型系统，编译器也强制使用类型，人们趋于使用更小的类、更短的方法，好让每个变量的定义都在自己的视野范围之内;对象是强类型的，代码编辑环境已经先进到在编译开始之前就侦测到类型错误的程度，所以类型编码的形式除纯属多余，也会引起其他弊端;

       <2.7.2>成员前缀

               也不必用m_前缀标明成员变量。应当把类和函数做的足够小，消除对成员前缀的需要。

       <2.7.3>接口和实现

               有时会出现采用编码的特殊情形。接口和实现必须选一个进行编码的话，作者宁可选择实现:

               EG：IShapeFactory(No)  PK  ShapeFactoryImp(Yes)

(2.8)避免思维映射

       不应当让读者在脑中把你的名称翻译为他们熟知的名称。这种名称经常出现在选择是使用问题领域术语还是解决方案术语。明确才是王道，编写他人可以理解的代码。

 

(2.9)类名

       类名和对象名应该是名词或者名词短语；

(2.10)方法名

       方法名应当是动词或者动词短语，属性访问器、修改器和断言应该根据其值命名;

(2.11)别扮可爱

       名称不要太耍宝

(2.12)每个概念对应一个词;

       对阅读者而言，一以贯之的命名法简直就是天降福音;

(2.13)别用双关语

       避免将同一单词用于不同目的,同一术语用于不同概念，基本上就是双关语了;

(2.14)使用解决方案领域名称

(2.15)使用源自所涉及领域的名称

(2.16)添加有意义的语境

       你需要用良好命名的类、函数或名称空间来放置名称，给读者提供语境。如果没这么做，给名称添加前缀就是最后一招了;

(2.17)不要添加没有用的语境

       只要短名称足够清楚，就要比长名称好。别给名称添加不必要的语境，精确正是命名的要点;

(2.18)结语

       取好名字，需要的良好的描述技巧和共有的文化背景；