本周读完第七部分。第七部分也是本书的最后一部分,讲的主题是软件工艺
。此部分一共分为五章,涉及的内容关联性不大,比较杂乱,主要包括代码的书写格式,以及良好的注释应该如何写。另外还包括一章专门讲程序员性格的,我觉得也是蛮有意思的。对于我这种天生脑子不太好使的同学,看完这一章之后似乎又看到了一丝前途的光明。最后两章讲的比较泛泛了,说的比较零散,涉及到很多常识类的大道理。下面简要总结一下。
第三十一章——布局与风格
本章主要讲了代码编写的格式问题。套用书中的话叫
(Page.729)本章转向计算机的编程的美学话题——程序源代码的布局。
在 布局的极端情况 这一节中,书中列举了一些格式混乱的代码,作为反面例子。
(Page.732)对于格式化的基本原理,好的布局凸显程序的逻辑结构。
好的代码书写能够更好的帮助我们阅读代码。我想但凡读过牛人写的代码的同学,应该会有所体会。
我记得当我刚开始写程序的时候,那个时候但凡看见一个程序写的熟练的人都非常的羡慕。曾经也多次感慨,啥时候咱也能像人家那样,熟练的写代码呢?
那么什么才是好布局呢?或者说良好布局的目标是什么呢?书中列出了几条(Page.735),
- 准确表现代码的逻辑结构
- 始终如一地表现代码的逻辑结构。
- 改善可读性
- 经得起修改
关于布局技术一节,提到「空白」、和「括号」。对于空白的使用,主要包括分组、空行、缩进等方式。括号就不用多说了,对于容易引起奇异的地方,最好用括号予以区分。一方面可以避免错误。另一方面增加可读性。
代码的布局风格,主要分为「纯块结构」、「模仿纯块结构」、「使用begin-end对(花括号)指定块边界」、「行尾布局」。下面针对不同的风格,摘录一些代码示例进行展示。
- 纯块布局(Page.738)
(Page.739)纯if块的Visual Basic示例
|
|
(Page.739)纯while块的Visual Basic示例
|
|
(Page.739)纯case块的Visual Basic示例
|
|
- 模仿纯块结构
(Page.741)模仿纯if块的C++示例
|
|
(Page.741)模仿纯while块的C++示例
|
|
(Page.741)模仿纯switchcase块的C++示例
|
|
- 使用begin-end对(花括号)指定块边界
(Page.742)使用begin和end作为if块边界的C++例子
|
|
(Page.742)使用begin和end作为while块边界的C++例子
|
|
(Page.743)使用begin和end作为switch/case代码块边界的C++例子
|
|
-
行尾布局 (Page.744)Visual Basic中较少见但看上去相当好的行尾布局示例
1 2 3 4 5 6
If (soldCount > 1000) Then markdown = 0.10 profit = 0.05 Else markdown = 0.05 End If
(Page.744)Visual Basic使用行尾布局的while代码块示例
1 2 3 4 5
While (pixelColor = Color_Red) statement1; statement2; ... Wend
(Page.744)更典型的Visual Basic示例,其行尾布局已失去应有的作用
1 2 3 4 5 6 7 8 9 10 11 12 13 14
If (soldCount > 10 And prevMonthSales > 10) Then If (soldCount > 100 And prevMonthSales > 10) Then If (soldCount > 1000) Then markdown = 0.1 profit = 0.05 Else markdown = 0.05 End If Else markdown = 0.025 End If Else markdown = 0.0 End If
好啦,列举了这么多的格式,到底那种风格最好呢?书中并没有给出答案,
(Page.745)所有风格都不绝对可靠,都偶尔需要进行“合理而明显”的折中。
随后书中对一些常见代码书写结构给出了一些建议。例如,
(Page.758))每行仅写一条语句
并针对此条语句给出了一些很有说服力的理由。对于数据声明的布局,和语句一样,也是每行只声明一个数据。这些理解起来都比较容易,在这里就不罗列代码了。
对于注释的布局也同样重要,注释写的好,也可以大大增进程序的可读性。我记得在我刚开始写代码的时候,增经有一段时期非常喜欢写注释,几乎每一行都要加上注释,以显得很专业,:D。其实,后来看书才了解到,什么应该写注释,什么时候没必要写。有时候不必要的注释让人看起来很冗余。反而会影响代码的阅读。
子程序的布局原则主要包括两个方面(Page.766),
- 用空行分割子程序的各部分
- 将子程序参数按标准缩进
类的布局分为两部分,一部分是类接口的布局,另一类是类实现的布局。类接口布局时,一般按如下顺序表示(Page.768):
- 说明类及其完整用法的头部注释
- 构造函数与析构函数
- public子程序
- protected子程序
- private子程序和数据成员
类实现的布局,通常按如下顺序排布(Page.768~769):
- 描述类所在文件之内容的头部注释
- 类数据
- public子程序
- protected子程序
- private子程序
书中也对文件和程序布局给出了一些建议(Page.771),
- 一个文件应只有一个类
- 文件的命名应该与类有关
- 在文件中清晰地分隔各子程序
- 按字母顺序排列子程序
第三十二章——自说明代码
本章主要将了程序中注释相关问题。但是本章在一开始就表明了注释的态度。例如,
(Page.778)在代码层文档中起主要作用的因素并非注释,而是好的编程风格。
(Page.779)对于精心编写的代码而言,注释不过是美丽衣裳上的小饰物而已。
其实,这两句话的意思是说,再清晰的注释也比不过简单明了的代码。对于什么情况下需要写注释,书中并没有给出定义,但是用了一段程序员之间的对话进行了表述。
对于注释的作用共分为六种(Page.786),
- 重复代码
- 解释代码
- 代码标记
- 概述代码
- 代码意图说明
- 传达代码无法表达的信息
随后书中提到,
(Page.788)对于完工的代码,只允许有的三种注释类型:代码无法表述的信息、目的性注释和概述性注释。
关于高效的注释,书中给出了几条指导原则(Page.788~Page.791),
- 采用不会打断或抑制修改的注释风格
- 用伪代码编程法减少注释时间
- 将注释继承到你的开发风格中
- 性能不是逃避注释的好借口
代码的注释技术分为两种,一种是单行注释。另一种是多行注释。在解释单/多行注释的过程中,分别说了注释数据和单/多行语句的方式,并通过一些小的代码片段简要说明了哪些注释会带来问题。这些小片段写的都很繁琐,所以这里也就不列举了,说一下这些注释的共性,很简单,就是繁琐。原因更多的是想让代码看起来美观,但却给维护带来了较高的成本。
第三十三章——个人性格
说实话,看完这章的整体感受是,对于以写程序为生,似乎又看到了一丝的光明…… 这里列举一些书中提到的经验。有些给了我很大的启发,对自己以后的规划起到了一些借鉴作用。
(Page.821)如何专注你的聪明才智,比你有多聪明更重要。
对于这句话,我觉得之前我走了不少弯路。前几年做的工作大多比较零散,坦白说没有往深度做,也没有这样的机会。当然了,主要原因还是在自己没有意识到这一点吧。我想以后,我会专注一些,把精力放到自己感兴趣的技术上来。
(Page.821)精通编程的人是那些了解自己头脑有多大局限性的人,都很谦虚
这一点,我觉得前几年我做的还不够。有的时候,回头想想我可能过于自信了,其实可能是因为太自卑了,所以才要表现的很自信吧。
对于求知欲这部分,有一段话讲的很好,
(Page.822)一旦承认自己的脑袋要理解多数程序还有难度,并意识到有效的编程就是去追寻改善这一境况的方式时,你就会开始需要付毕生精力的漫长求索过程。在成为高手的过程中,对技术的事物的求知欲具有压倒一切的重要性。
对于这段话来说,我发现我做的还差很多,虽然我早发现自己技术上差的还很多,但是我不知道能不能用毕生的精力去追求,我想我能做的就是尽自己最大的努力。
(Page.823)学习编程的一个特别好的途径是研究高手的程序。
这一点在很多高手的经验之谈中经常会看到。所谓的捷径,我想也就是这个吧,:)。
(Page.826)拒绝认错是一个让人特别讨厌的习惯。
现实中,见过很多这样的朋友。大部分原因可能是因为面子吧,呵呵。对于这一点,貌似全世界的程序员都有这个通病,只不过有的人比较坦诚,有的人比较猥琐。我自己觉得,但凡是坦诚认错的人,更表明了他有信心。拉不下脸来认错的人,其实是没有自信的表现,最后可能让自己错过纠正错误的机会,其实是不明智的表现。
书中有一段在讲经验
。我很认可其中的观点,
(Page.831)与其他行业相比,软件开发行业的经验比书本知识价值要小,…。
这一点比较好理解,但是不容易被大多数行业内的人接受,这需要时间慢慢转变。
第三十四章——软件工艺的话题
(Page.837)致力于降低复杂度是软件开发的核心。
我想这一句话总结了本书的主旨。本书的所有章节都是在围绕这个话题展开,:)。本章后面讲的就不多说了,基本上属于总结性的话题。
第三十五章——何处有更多信息
呵呵,题目很清楚。本章列出了一些不同阶段程序员可以参考的资料。这里就不多说了。