编写可读代码的艺术

上传人:平*** 文档编号:15481010 上传时间:2017-11-04 格式:DOC 页数:7 大小:63.29KB
返回 下载 相关 举报
编写可读代码的艺术_第1页
第1页 / 共7页
编写可读代码的艺术_第2页
第2页 / 共7页
编写可读代码的艺术_第3页
第3页 / 共7页
编写可读代码的艺术_第4页
第4页 / 共7页
编写可读代码的艺术_第5页
第5页 / 共7页
点击查看更多>>
资源描述

《编写可读代码的艺术》由会员分享,可在线阅读,更多相关《编写可读代码的艺术(7页珍藏版)》请在金锄头文库上搜索。

1、引言细节决定成败,思路清晰、言简意赅的代码让程序员一目了然;而格式凌乱、拖沓冗长的代码让程序员一头雾水。除了可以正确运行以外,优秀的代码必须具备良好的可读性,编写的代码要使其他人能在最短的时间内理解才行。本书旨在强调代码对人的友好性和可读性。本书关注编码的细节,总结了很多提高代码可读性的小技巧,看似都微不足道,但是对于整个软件系统的开发而言,它们与宏观的架构决策、设计思想、指导原则同样重要。编码不仅仅只是一种技术,也是一门艺术,编写可读性高的代码尤其如此。如果你要成为一位优秀的程序员,要想开发出高质量的软件系统,必须从细处着手,做到内外兼修,本书将为你提供有效的指导。主要内容:简化命名、注释和

2、格式的方法,使每行代码都言简意赅。梳理程序中的循环、逻辑和变量来减小复杂度并理清思路。在函数级别解决问题,例如重新组织代码块,使其一次只做一件事。编写有效的测试代码,使其全面而简洁,同时可读性更高。第一章 代码应当易于理解关键思想:代码应当易于理解。例如:/代码 1For (Node* node=list-head;node!=null ;node=node-next)Print(node-data);/代码二Node* node=list-head;If(node=null) return;While(node-next!=null)Print(node-data);Node=node-ne

3、xt;If(node!=null) print(node-data);总结:尽管上面两段代码行为完全一样,但代码 1 的更容易理解。可读性基本定理:代码的写法应当使别人理解它所需的时间最小化。注意:代码不仅仅是给现在的你看的,也是给一星期后或是一个月以后的你看的。第二章 把信息装到名字里关键思想:把信息装到名字中。1. 选择专业的词把信息装到名字中包括要选择非常专业的词,并且避免使用“空洞”的词。例如, “get”这个词就非常不专业。比如:getPage()如果表示从互联网上得到一个页面可以用 fetchPage()或 downloadPage()替换。下面是一个 BinaryTree 类的例

4、子:class BinaryTreeint Size();你会觉得 Size() 返回什么呢?树的高度,节点数,还是树在内存中所占的空间?问题是 Size() 没有承载更多的信息,可以由 Height()、NumNodes()或者 MemoryBytes() 代替。另外一个例子,假设你有某个 Thread 类:class Threadvoid Stop();Stop() 这个名字还可以,但还可以有更多专业的名字,例如如果不能恢复了,用 Skill() 会更准确些,或者 Pause() ,如果有其他方法让它 Resume() 下面这些单词更具有表现力。单词 更多选择Send Deliver di

5、spatch announce distribute routeFind Search extract locate recoverStart Launch create begin openMake Create set up build generate compose add new2. 避免范范的名词避免使用像 tmp retval foo 这样范范的名字(注:tmp 这个名字只适用于短期存在且临时行为其主要存在因素的变量)例如:交换两个变量If(right bytes_received)) ,把改变的值写在左边并且把更稳定的值写在右边更好一些(white(bytes_received

6、 bytes_expected)) ;2.你也可以重新排列 if/else 语句中的语句块。通常来讲,先处理正确的/简单的/ 有趣的情况。有时这些准则会冲突,但是当不冲突时,这是要遵循的经验法则。把赋值操作放在 if 条件中,很多程序员把参数的顺序调换一下。如:if(null=obj)3.某些编程结构,像三目运算符(:?)、do/While 循环,以及 goto 经常导致代码的可读性变差。最好不要使用它们,因为总是有更整洁的代替方式。4.嵌套的代码块需要更加集中精力去理解。每层新的嵌套都需要把更多的上下文“压入栈” 。应该把它们改写成“线性”的代码来避免深嵌套。5.通常来讲提早返回/跳过可以减

7、少嵌套并让代码整洁。 “保护语句” (在函数顶部处理简单的情况时)尤其有用。第 8 章 拆分超长表达式关键思想:把你的超长表达式拆分成更容易理解的小块。 引入“解释变量”来代表较长的子表达式的好处:它把巨大的表达式拆成小段;它通过用简单的名字描述子表达式来让代码文档化;它帮助读者识别代码中的主要概念;德摩根定理有时可简化布尔表达式(例如 if(!(a&!b)变成 if(!a|b));尽量使 if 语句内只有一个活两个表达式,有时需要把问题反向或者考虑目标的对立面;拆分独立表达式的方法同样适用于大的代码块; 第 9 章 变量与可读性关键思想:让你的变量对尽量少的代码行可见。变量的草率运用带来的问

8、题:1. 变量越多,就越难全部跟踪他们的动向。2. 变量的作用域3. 减少变量,即那些妨碍的变量。我们给出几个例子来演示如何通过立刻处理结果来消除“中间结果”变量;避免使用全局变量(注意:在 javascript 中声明变量时省略 var关键字这个变量会放在全局作用域中)4. 减小每个变量的作用域,越小越好。把变量移到一个又最小代码可以看到它的地方。眼不见,心不烦;5. 只写一次的变量更好。那些只设置一次值的变量(或者 const、final、常量)使得代码更容易理解;操作一个变量的地方越多,越难确定它的当前值。第 10 章 抽取不相关的子问题把一般代码和项目专有代码分开。其结果是,大部分代码

9、都是一般代码。通过建立一大组库和辅助函数来解决一般问题,剩下的只是让你的程序与众不同的核心部分。这个技巧使程序员只关注有良好定义的小问题,这些问题已经同项目的其它部分脱离。其结果是,对于这些子问题的解决方案倾向于更加完整和正确。你也可以在以后重用它们。第 11 章 一次只做一件事一次只做一类事,相同类的事情放到一起去做。如果你有很难读的代码,尝试把它所做的所有任务列出来。其中一些任务可以很容易地变成单独的函数(或类)。其他的可以简单地成为一个函数中的逻辑“段落”。具体如何拆分这些任务没有它们已经分开这个事实那样重要,难的是要准确地描述你的程序所做的所有这些小事情。第 12 章 把想法变成代码用

10、自然语言描述程序然后用这个描述来帮助你写出更自然的代码。这个技巧出人意料地简单,但很强大,看到你在描述中所用的词和短语还可以帮助你发现哪些子问题可以拆分出来。“用自然语言说事情”的过程不仅可以用于写代码,在遇到解决不了的问题时还可以找到解决问题的办法。如果你不能把问题说明白或者用词语做设计,估计是缺少了什么东西或者什么东西缺少定义,把一个问题(或想法)变成语言真的可以让它变得具体。第 13 章 少写代码每行新的代码都需要测试、写文档和维护。另外,代码库中的代码越多,它就越“重”,而且在其上开发就越难。避免编写新代码的方法:从项目中消除不必要的功能,不要过度设计;重新考虑需求,解决版本最简单的问题,只要能完成工作就行;经常性地通读标准库的整个 API,保持对它们的熟悉程度;

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 办公文档 > 其它办公文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号