C语言代码质量与架构调整（二）

一、代码质量和架构阶段一

1.1、读书《代码整洁之道》

第三章函数

1、不要重复，尽量写小函数。

2、小函数可以有好几个出口和入口更具表达力，但是对于大的函数应尽量保证一个入口和一个出口。

3、写代码和写文章是一样的，需要反复打磨。

4、最理想的方式是不要带参，但是有时候也可以带参更易于理解，要分清场合，可以用结构体如果多个参数的话。

5、函数的抽象结构应该是自顶向下的方式。

6、函数应该只做一件事并把这件事情做好。

第四章注释

1、再好的注释都无法掩盖糟糕的代码，所以多花点时间怎么写清楚代码上。

2、有些注释是必须的，比如法律信息。

3、更好的注释是代码的。

4、有时作为警告某个操作的注释也是有必要的。.

5、以前没有提交日志这些日式的注释还有用，但是有了提交日志，这些只会冗长。

6、注释掉的代码可以完全删除，因为有了代码修改提交日志。

第七章错误处理

1、别轻易返回一个NULL值，最好的做法是在编程时禁止传入NULL值。

2、整洁的代码是可读的，但也要强固。

第九章单元测试

1、整洁的测试应当遵循的原则是：快速、独立、可重复、自足验证、及时。

1.2、读《C现代编程》

第三章C语言和面向对象

c程序总是冗长而又单调的感觉，一个函数有长达百行代码、相同处理的函数分布在各个文件中。

由于设计模式是以使用面向对象语言为前提的，所以很多人会觉得使用C编程时无法使用设计模式。但实际上C也可以面向对象编程。只要能活用设计模式，就可以极大地改善程序结构，使程序各部分解耦，完全独立工作。

1、无需对外公开变量和函数，使用static修饰符，完成模块化的隔离。

2、使用宏方便结构体初始化。

3、使用结构体减小传递的函数参数。使用宏封装检查参数范围。

4、利用结构体完成继承，利用函数封装指针和结构体实现相同功能的不同实现完成多态。

5、封装就是抽象化，数据访问受限可以用const修饰符，也可以用函数名来约束。

6、虚函数：如果函数指针太多导致初始化浪费内存，可以采用静态全局变量的数组来实现共同的函数指针初始化。

第四章C语言与设计模式

参考设计模式地址：https://blog.csdn.net/feixiaoxing/article/details/7188574

1、状态模式，如CD播放音乐的状态

2、涉及到资源处理和资源管理的代码，最好的方式是封装资源处理函数，而后就剩下资源的管理函数

伪代码就是：fun{open(fd)  process(fd)  close(fd)}，这样就能保证获取资源、处理资源、关闭资源独立处理。

第五章C语言与重构

1、代码被修改后很容易变得晦涩难懂，看到这样的代码，谁都想直接关掉编辑器，不再去理会他们。

糟糕代码的特征：

一个函数长达数百行

代码缩进不正齐，难以把握代码结构

存在像i2、i3这样已有的变量名和函数名加上数字而组成的新变量名和函数名，而且它们的大部分处理内容完全相同。

代码中还残留“以后修改”这样的注释，不免让人担心现在的代码是否能正常工作。

2、测试驱动开发，Google Test

3、重构时应该明确哪些内容需要对外公开，哪些内容不应该对外公开，并将对外公开的部分尽量减至最少。这是因为对外公开的部分越少，以后改善代码结构时对外部造成的影响也越小。

腐烂的代码绝非开发人员有意为之，肯定是由某些客观原因造成的。

4、注释特别多，代码重复，不管如何复制现有的代码都会让人心安理得，相信很多人员都无法抵挡这种诱惑。但是一旦我们在一处找到BUG，就不得不所有复制这段代码的地方修改。高级处理和底层处理混杂。

5、使用工具重构，对影响范围小的代码重构，对修改后可以在编译和链接时发现错误的代码进行重构。

6、提取函数，精简函数。

7、经常发生变化的文件或是逻辑处理在哪里？特别复杂，且修改时经常出现BUG的代码在哪里？几乎不会发生改变的代码在哪里？

第六章持续集成与部署

1.3、读《编写可读代码的艺术》

很多提高代码可读性的小技巧，看似都微不足道，但是对于整个软件系统而言，它们与宏观的架构决策、设计思想、指导原则同样重要。编码是一种技术，也是一门艺术，编写可读性高的代码尤其如此。如果你想要成为一位优秀的程序员，要学会从细处着手。

主要内容包括：简化命名、注释和格式的方法，使每行代码都言简意赅。梳理程序中的循环、逻辑和变量来减小复杂度并理清思路。在函数级别解决问题。例如重新组织代码块，使其一次只做一件事。编写有效的测试代码，使其全面而简洁，同时可读性更高。

表面层次上的改进、简化循环和逻辑、重新组织你的代码

第一部分、表面层次的改进

第一章、可读性的衡量

第二章、把信息装到名字里

1、选择专业的词、避免泛泛的名字、用具体的名字代替抽象的名字、使用前缀或后缀给名字附带更多的信息、决定名字的长度、利用名字的格式来表达含义。

第三章、不会误解的名字

在决定使用一个名字时，要吹毛求疵一点，来想象一下你的名字会被误解成什么。

第四章、审美

使用一致的布局，让读者很快就习惯这种风格

让相似的代码看上去相似

把相关的代码行分组，形成代码块。

选择一个有意义的顺序。

用空行来大把大块代码分成逻辑上的段落。

让代码按列对齐可以让代码更容易浏览。

第五章、该写什么样的注释

了解什么不需要注释

用代码记录你的思想

站在读者的角度，去想象他们需要知道什么

好代码》坏代码+注释

注释的目的是帮助作者了解在写代码时已经知道的那些事情。

不需要的注释，能从代码很快推断的事实，用来粉饰烂代码的注释。

预料到代码中哪些部分会让读者说“啊”，给它们加上注释。

为普通读者意料之外的行为加上注释。

在文件和类的使用上全局观的注释解释所有部分是如何工作的。

用注释来总结代码块，使读者不至迷失在细节中。

第六章、写出言简意赅的注释

第二部分、简化循环和逻辑

第七章、把控制流变得易读

容易变化的放在右侧（但是会容易造成== 和= 这种编写错误，要看编译器是否有警告了）

不要读者有在if和else中有出栈进栈的感觉。通常来讲，先处理正确的简单的有趣的情况。有时可能会有冲突。

在某些编程结构中，像三目运算符、do/while循环，以及goto常会导致代码的可读性变差。最好不要使用他们，因为总是有更整洁的代替方法。（这里就是不允许用goto，而采用do/whiel(0)来代替）。

嵌套的代码块需要更加集中精力去理解。每层新的嵌套都需要读者把更多的上下文压入栈。应该八他们改写成更加线性的代码来避免嵌套。

通常来讲提早返回可以减少嵌套，并让代码整洁。保护语句（在函数顶部处理更简单的情况时）尤其有用。

第八章、拆分超长的表达式

大多数人同时只能考虑3~4件事情，代码的表达式越长越难以理解。

找到更优雅的方式需要创造力，逆向思考？

解释变量来代替表达式。

第九章、变量与可读性

减少变量可以减少人思考。

减少变量但是不能改变他的可读性。

减少中间变量，减少控制变量

缩小变量的作用域，避免全局变量。把大的文件拆分，大的函数拆分，大的类拆分

C++和JAVA会限定变量作用域if、for、try。

只写一次的变量（const、final、常量）使代码更容易理解。

第三部分、重新组织代码

第十章、抽取不相关的子问题

抽取出那些与程序主要目的的不相关的子问题

从你的代码中拆分出越多的独立库越多越好。因为你代码其他部分会更小而且更容易思考。

你永远都不要安于使用不理想的接口，你总是可以创建你自己的包装函数来隐藏接口的粗陋细节，让他不要为你的阻碍。

第十一章、一次只做一件事

同时在做几件事的代码难以理解。

如果你有难读的代码，尝试把它所做的所有任务列出来。其中一些任务可以很容易地变成单独的函数。其他的可以简单的成为一个函数的逻辑段落

第十二章、把想法变成代码

先用自然语言描述代码，然后用这个描述来帮助你找到更整洁的解决方案。

把一个问题用自然语言描述出来，往往就能找到解决的办法。

第十三章、少写代码

删除无用代码，提高代码复用率，重新考虑需求，解决版本最简单的问题，不要过度设计。

第四部分、精选话题

第十四章、测试与可读性

对测试友好的设计往往很自然的产生有良好组织的代码

比较难解耦的代码：使用全局变量，对外部组件有大量依赖的代码，代码有不确定的行为。

比较好的测试代码：类中只有很少或者没有内部状态，类或者函数只做一件事，依赖少，低耦合，函数接口定义简单明确。

第十五章、设计并改进

你可能已经注意到，我们已经两次通过同事来帮助我们解决问题了。询问外部视角的观点是测试你的代码是否“对用户友好”的好办法。要试着对他们的第一映像持开放的态度，因为其他人可能会有同样的结论。并且这些其他人可能就包含六个月之后的你自己。

从写一个幼稚的方案开始，然后设计不同的挑战方案：速度和内存的使用情况。

二、代码质量和架构阶段二

2.1、《修改代码的艺术》

第一章、修改软件

添加新特性（需求）、修正bUG（缺陷）、改善设计（重构）、优化资源使用（优化）

第二章、带着反馈工作

回归测试、单元测试

确定改动点、找出测试点、解依赖、编写测试、修改和重构

第三章、感知和分离

 

三、读软件工程和科普书

3.1、读《大教堂和集市》

1、集市式模式的编程，让更多无私编程的人出现，此外更早的暴露你的编程，让别人去发现其中的BUG。

2、人们 一般在一项任务处于一种适当难度范围的时 候享有乐趣； 不要太简单了至于无聊，不要太难了不好实现。一个快乐程 序员是一个既没有被浪费也没有被错误制定的目标和烦人过 程摩擦所压倒的人。乐趣通往效 率。

3.2、读《编程人生》

1、大多数都认同，保持代码的可读性非常重要，同时最难查的BUG是出现在并发代码中。

3.3、读《人件》

1、开心的工作环境、让人工作的开心、有挑战的工作。管理者的作用不是让大家去工作，而是创造环境，让大家可以顺利开展工作。

2、错误在所难免。营造一个不容易任何失误的氛围会让大家持有戒心。他们不愿去尝试那些有可能变坏的事情。要鼓励大家犯错。要让每个人感觉到独特性。

3、对于编程这种脑力劳动者，工作太长会扼杀创造性。压力大不会让人工作得更好，只是工作的更快。工作得更快就不得不牺牲质量及自身工作体验。

4、不给任何时间压力，只需要说“你做完告诉我一声就行”。

3.4、读《人月神话》

1、软件编程的快乐来源于创建事物的，开发了对他人有用的东西，组装零件的快乐。很少有一种介质如此灵活，如此易于重建和精炼，可以实现概念上的设想。而痛苦来源于这种易变带来的追求完美，寻找BUG的痛苦。

2、编程的复杂性、一致性、可变性和不可见性是其根本属性。无论是面向对象编程还是可视化编程都很难改变这种思想上的活动。