代码整洁之道(一)

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

阅读进度:

第一章  整洁代码

第二章  有意义的命名

第三章  函数

第四章  注释

第五章  格式

第六章  对象和数据结构

第七章  错误处理

第十章  类

 

序:

<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)结语

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

原文地址:https://www.cnblogs.com/BlueGeek/p/2887225.html