原代码的阅读方法(3)

90.重要的数据结构操作算法一般用函数参数或模板参数来参数化.

91.图的结点常常顺序地存储在数组中, 链接到链表中, 或通过图的边链接起来.

92.图中的边一般不是隐式地通过指针, 就是显式地作为独立的结构来表示.

93.图的边经常存储为动态分配的数组或链表, 在这两种情况下, 边都锚定在图的结点上.

94.在无向图中, 表达数据时应该将所有的结点看作是等同的, 类似地, 进行处理任务的代码也不应该基于它们的方向来区分边.

95.在非连通图中, 执行遍历代码应该能够接通孤立的子图.

96.处理包含回路的图时, 遍历代码应该避免在处理图的回路进入循环.

97.复杂的图结构中, 可能隐藏着其他类型的独立结构.

+++++++++++++++++

第五章: 高级控制流程

+++++++++++++++++

98.采用递归定义的算法和数据结构经常用递归的函数定义来实现.

99.推理递归函数时, 要从基准落伍测试开始, 并认证每次递归调用如何逐渐接近非递归基准范例代码.

100.简单的语言常常使用一系列遵循该语言语法结构的函数进行语法分析.

101.推理互递归函数时, 要基于底层概念的递归定义.

102.尾递归调用等同于一个回到函数开始处的循环.

103.将throws子句从方法的定义中移除, 然后运行Java编译器对类的源代码进行编译, 就可以容易地找到那些可能隐式地生成异常的方法.

104.在多处理器计算机上运行的代码常常围绕进程或线程进行组织.

105.工作群并行模型用于在多个处理器间分配工作, 或者创建一个任务池, 然后将大量需要处理标准化的工作进行分配.

106.基于线程的管理者/工人并行模型一般将耗时的或阻塞的操作分配给工人子任务, 从而维护中心任务的响应性.

107.基于进程的管理者/工人并行模型一般用来重用现有的程序, 或用定义良好的接口组织和分离粗粒度的系统模块.

108.基于流水线的并行处理中, 每个任务都接收到一些输入, 对它们进行一些处理, 并将生成的输出传递给下一个任务, 进行不同的处理.

109.竞争条件很难捉摸, 相关的代码常常会将竞争条件扩散到多个函数或模块; 因而, 很难隔离由于竞争条件导致的问题.

110.对于出现在信号处理器中的数据结构操作代码和库调用要保持高度警惕.

111.在阅读包含宏的代码时, 要注意, 宏既非函数, 也非语句.

112.do…while(0)块中的宏等同于控制块中的语句.

113.宏可以访问在它的使用点可见的所有局部变量.

114.宏调用可改变参数的值

115.基于宏的标记拼接能够创建新的标记符. +++++++++++++++++

第六章: 应对大型项目

+++++++++++++++++

116.我们可以通过浏览项目的源代码树—包含项目源代码的层次目录结构, 来分析一个项目的组织方式. 源码树常常能够反映出项目在构架和软件过程上的结构.

117.应用程序的源代码树经常是该应用程序的部署结构的镜像.

118.不要被庞大的源代码集合吓倒; 它们一般比小型的专门项目组织得更出色.

119.当您首次接触一个大型项目时, 要花一些时间来熟悉项目的目录树结构.

120.项目的源代码远不只是编译后可以获得可执行程序的计算机语言指令; 一个项目的源码树一般还包括规格说明|最终用户和开发人员文档|

测试脚本|多媒体资源|编译工具|例子|本地化文件|修订历史|安装过程和许可信息.

121.大型项目的编译过程一般声明性地借助依赖关系来说明. 依赖关系由工具程序, 如make及其派生程序, 转换成具体的编译行动.

122.大型项目中, 制作文件常常由配置步骤动态地生成; 在分析制作文件之前, 需要先执行项目特定的配置.

123.检查大型编译过程的各个步骤时, 可以使用make程序的-n开关进行预演.

124.修订控制系统提供从储存库中获取源代码最新版本的方式.

125.可以使用相关的命令, 显示可执行文件中的修订标识关键字, 从而将可执行文件与它的源代码匹配起来.

126.使用修订日志中出现的bug跟踪系统内的编号, 可以在bug跟踪系统的数据库中找到有关的问题的说明.

127.可以使用修订控制系统的版本储存库, 找出特定的变更是如何实现的.

128.定制编译工具用在软件开发过程的许多方面, 包括配置|编译过程管理|代码的生成|测试和文档编制.

129.程序的调试输出可以帮助我们理解程序控制流程和数据元素的关键部分.

130.跟踪语句所在的地点一般也是算法运行的重要部分.

131.可以用断言来检验算法运作的步骤|函数接收的参数|程序的控制流程|底层硬件的属性和测试用例的结果.

132.可以使用对算法进行检验的断言来证实您对算法运作的理解, 或将它作为推理的起点.

133.对函数参数和结果的断言经常记录了函数的前置条件和后置条件.

134.我们可以将测试整个函数的断言作为每个给定函数的规格说明.

135.测试用例可以部分地代替函数规格说明.

136.可以使用测试用例的输入数据对源代码序列进行预演.

+++++++++++++++++++

第七章: 编码规范和约定

+++++++++++++++++++

137.了解了给定代码库所遵循的文件组织方式后, 就能更有效率地浏览它的源代码.

138.阅读代码时, 首先要确保您的编辑器或优美打印程序的tab设置, 与代码遵循的风格规范一致.

139.可以使用代码块的缩进, 快速地掌握代码的总体结构.

140.对编排不一致的代码, 应该立即给予足够的警惕.

141.分析代码时, 对标记为XXX, FIXME和TODO的代码序列要格外注意: 错误可能就潜伏在其中.

142.常量使用大写字母命名, 单词用下划线分隔.

143.在遵循Java编码规范的程序中, 包名(package name)总是从一个顶级的域名开始(例如, org, com), 类名和接口名由大写字母开始, 方法和变量名由小写字母开始.

144.用户界面控件名称之前的匈牙利记法的前缀类型标记可以帮助我们确定它的作用.

145.不同的编程规范对可移植构造的构成有不同的主张.

146.在审查代码的可移植性, 或以某种给定的编码规范作为指南时, 要注意了解规范对可移植性需求的界定与限制.

147.如果GUI功能都使用相应的编程结构来实现, 则通过代码审查可以轻易地验证给定用户界面的规格说明是否被正确地采用.

148.了解项目编译过程的组织方式与自动化方式之后, 我们就能够快速地阅读与理解对应的编译规则.

149.当检查系统的发布过程时, 常常可以将相应发行格式的需求作为基准. ++++++++++++

第八章： 文档 ++++++++++++

150.阅读代码时, 应该尽可能地利用任何能够得到的文档.

151.阅读一小时代码所得到的信息只不过相当于阅读一分钟文档.

152.使用系统的规格说明文档, 了解所阅读代码的运行环境.

153.软件需求规格说明是阅读和评估代码的基准.

154.可以将系统的设计规格说明作为认知代码结构的路线图, 阅读具体代码的指引.

155.测试规格说明文档为我们提供可以用来对代码进行预演的数据.

156.在接触一个未知系统时, 功能性的描述和用户指南可以提供重要的背景信息,从而更好 …… 此处隐藏：2287字，全部文档内容请下载后查看。喜欢就下载吧 ……