最新消息:想得多,做的少。一天到晚瞎鸡巴搞。

《代码整洁之道》部分摘录

读书 阿虚 958浏览 0评论

.      今天花了一天时间看了部分章节并且做了一些摘录,没有打算看完整本书的想法。因为目前来说,我的编程能力还没有达到能阅读正本书籍的能力…..

.      个人的代码风格实在是很糟糕。看了部分我能用得上的地方发现自己以前写的风格完全没有能符合上面的规定。 哦不,除了一条规定:“代码一行不要超过120字符”。

.      这本书的理念就是写代码如同读小说那样轻松,不需要那些多余的注释。单靠变量名和函数名即可弄清楚写代码人的思路。以及构造短小但是却分工明确的结构化编程。但是这本书里面的示例代码短小到都让我有种:“你TM在逗我?”的想法。。。。

———————————————–

Bjarne:糟糕的代码想做太多事,它意图混乱、目的含混。整洁的代码力求集中。每个函数、每个类和每个模块都全神贯注于一事。完全不受四周细节的干扰和污染。

Ron:减少重复代码,提高表达力,提早构建简单抽象。这就是我写整洁代码的方法。

———————————————–

有意义的命名,一旦发现有更好名称就立刻替换掉就的。

.      废话是另一种没意义的区分。假设你有一个Product类。如果还有一个ProductInfo或者ProductData类。他们名称虽然不同意思却无区别。info和data就像a,an和the一样。是意义含混的废话。

.      类名和对象名英国是名词或名词短语。如Sustomer、WidiPage、Account和AddressParser。避免使用Mangaer、Processor、Data或Info这样类名。类名不应当是动词。

.      函数名因当是动词或动词短语。如PostPayment、deletePage或save属性访问器、修改器、断言英国更具其名命名。并且依据Javabean标准加上set、get和is前缀。

.      只要名称足够清除,就要比长名称好。别给名称添加不必要语境。

如何写好函数

.      函数第一规则要短小,第二规则要更短小。。。。每行不该有150个字符,函数也不该有100行长。20行封顶最佳。

.      函数应该做一件事情,做好这件事情,只做这一件事情。

自顶向下读代码:向下规则

.      想要代码拥有自顶向下的阅读顺序。我们想要让每个函数后面都跟着位于下一抽象层的函数,这样一来,在查看函数列表时,将能循抽象层向下阅读了。我把这叫做向下规则。

要容纳设置和分拆步骤,就先容纳设置步骤,然后纳入测试页面内容,在纳入分拆步骤。

要容纳设置步骤,如果是套件,就纳入套件设置步骤,然后再纳入普通设置步骤。

要容纳套件设置步骤,先搜索“SuiteSetUp”页面上的上级继承关系,再添加一个包括该页面路径的语句

要搜索….

函数参数

.      最理想0参数,其次一参数,再次二参数,尽量避免三参数。

.      如果函数看来需要2个3个或以上参数,就说明其中一些参数改封装为结构体或类了。

.      避免使用输出参数。

 

使用异常代替返错误码。

抽离Try/Catch代码块

.      它们丑陋不堪。。。。它们搞乱了代码结构,把错误处理与正常流程混为一谈。最好把try和catch代码块主体部分抽离出来,另外形成函数。

try{

delete(page)

}

catch(Exception e){

logError(e);

}

void  deletePageAndAllReferences(page){

CloseHandle(page.handle);

}

void logError(e){

printf(“Error \r\n”);

}

.      函数只应该做一件事情。错误处理就是一件事情。因此,错误处理的函数不该做其他事。这意味着(如上例)如果关键字try在某个函数中存在,它就应该是这个函数的第一个单词,而且在catch代码块后面也不该有其他内容。

 

结构化编程

.      每个函数、函数中的每个代码块都应该有一个入口、一个出口。遵循这些规则,意味着在每个函数中值该有一个return语句,循环中不能有break或continue语句,而且永永远远不能有任何goto语句。

.      只要保持短小,偶尔出现return、break或continue语句没有坏处,甚至还比单入单出原则更具有表达力。另外一方面,goto只在大函数中才有道理,所以应该尽量避免使用。

 

如何写出这样的函数

刚写函数式,一开始都冗长而复杂。有太多缩进和嵌套循环。有过长的参数列表。名称是随意取的,也会有重复代码,。不过我会配上一套单元测试,覆盖每行丑陋的代码。

然后我打磨这些代码,分解函数,修改名称,消除重复。我缩短和重新安置方法。又是后我还拆散类。同时保持测试通过。

最后,遵循本章列出来的规则,我组装好这些函数。

注释

.      别给糟糕的代码加注释,重写吧 –Brian W.Kernighan与P.J.Plaugher

.      若编程有足够表达能力,或者我们长于用这些语言表达意图。那就不需要注释,也许根本不需要。

.      注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。注释总是一种失败,我们总无法找到不用注释就能表达自我的方法。所以总要有注释,这并不值得庆贺。

.      注释的时间存在的越久,就里所其描述的代码越远。越来越变得全然错误。原因很简单。程序员都不能坚持维护注释。

.      带有少量注释的整洁而有表达能力的代码,要比带有大量注释的零碎而复杂的代码像样得多。与其花时间编写解释你搞出来的糟糕代码的注释,不如花时间清洁那对糟糕的代码。

.      能用注释的地方:提供基本信息,警告其他程序员会出现某种后果的注释。

.      能用函数或变量就别用注释

.      直接把代码注释掉是讨厌的做法,别这么干。

 

格式

.      代码格式很重要,代码格式不可忽略,必须严肃处理。

.      成员变量应该放在类的底部(C++)或顶部(Java)。而不是随意在成员函数间定义。

.      相关函数若某个函数调用了另外一个,就应该吧他们放到一起。而且调用者应该尽可能放在被调用者上面,这样程序就有个自然顺序。

.      概念相关的代码应该放到一起,相关性越强。彼此之间的雨里就该越短。

.      一行代码不超过120个字符。

 

.      类应该更短小。

.      内聚:类应该只有少量实体变量。类中的每个方法都应该操作一个活多个这种变量。通常而言,方法操作的变量越多,就越黏聚到类上。如果一个类中的每个变量都被每个方法所使用,则该类具有最大的内聚性。

.      保持内聚性就会得到许多短小的类:仅仅将较大的函数切割为小函数,就讲到之处更多的类出现。想想看一个有许多变量的大函数。你想把函数中某一小部分拆解成单独的函数。不过,你想要拆出来的代码使用了该函数中声明的四个变量。是否必须将这四个变量都作为参数传递到新函数中去呢?

.      完全没必要。只要将四个变量提升为类的实体变量,完全无需传递任何变量就能拆解代码了。应该很容易将函数拆分为小块。如果有些函数想要共享某些变了,为什么不让他们拥有自己的类呢?当类丧失了内聚性,就拆分他。所以,将大函数拆分为许多小函数,往往也是将类拆分为多个小类的实际。程序会更加有组织,也会拥有更为透明的结构。

转载请注明:虚无 » 《代码整洁之道》部分摘录

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址