1. 如何编写高质量的代码
1. 打好基础
写出高质量代码，并不是搭建空中楼阁，需要有一定的基础，这里我重点强调与代码质量密切相关的几点：
掌握好开发语言，比如做Android就必须对Java足够熟悉，《Effective Java》一书就是教授大家如何更好得掌握Java, 写出高质量Java代码。
熟悉开发平台, 不同的开发平台，有不同的API, 有不同的工作原理，同样是Java代码，在PC上写与Android上写很多地方不一样，要去熟悉Android编程的一些特性，iOS编程的一些特性，了解清楚这些，才能写出更加地道的代码，充分发挥各自平台的优势。
基础的数据结构与算法，掌握好这些在解决一些特定问题时，可以以更加优雅有效的方式处理。
基础的设计原则，无需完全掌握23种经典设计模式，只需要了解一些常用的设计原则即可，甚至你也可以只了解什么是低耦合，并在你的代码中坚持实践，也能写出很不错的代码。
2. 代码标准
代码标准在团队合作中尤为重要，谁也不希望一个项目中代码风格各异，看得让人糟心，即便是个人开发者，现在也需要跟各种开源项目打交道。标准怎么定是一个老生常谈的话题，我个人职业生涯中经历过很多次的代码标准讨论会议，C++, C#, Java等等，大家有时会坚持自己的习惯不肯退让。可现如今时代不一样了，Google等大厂已经为我们制定好了各种标准，不用争了，就用这些业界标准吧。
3. 想好再写
除非你很清楚你要怎么做，否则我不建议边做边想。
你真的搞清楚你要解决的问题是什么了吗？你的方案是否能有效？有没有更优雅简单的方案？准备怎么设计它，必要的情况下，需要有设计文档，复杂一些的设计需要有同行评审，写代码其实是很简单的事情，前提是你得先想清楚。
4. 代码重构
重构对于代码质量的重要性不言而喻，反正我是很难一次把代码写得让自己满意、无可挑剔，《重构》这本书作为业内经典也理应人人必读，也有其他类似的教授重构技巧的书，有些也非常不错，遗憾的是我发现很多工作多年的同学甚至都没有了解过重构的概念。
5. 技术债务
知乎上最近有个热门问题《为什么有些大公司技术弱爆了?》，其实里面提到的很多归根结底都是技术债务问题，这在一些大公司尤为常见。技术债务话题太大，但就代码质量而言，我只想提一下不要因为这些债是前人留下的你就不去管，现实是没有多少机会让你从一个清爽清新的项目开始做起，你不得不去面对这些，你也没法完全不跟这些所谓的烂代码打交道。
因此我建议各位：当你负责一个小模块时，除了把它做好之外，也要顺便将与之纠缠在一起的技术债务还掉，因为这些债务最终将是整个团队来共同承担，任何一个人都别想独善其身，如果你还对高质量代码有追求的话。
作为团队的技术负责人，也要顶住压力，鼓励大家勇于做出尝试，引导大家不断改进代码质量，不要总是畏手畏脚，停滞不前，真要背锅也得上，要有担当。
6. 代码审查
我曾经听过一些较高级别的技术分享，竟然还不时听到一些呼吁大家要做代码审查的主题，我以为在这个级别的技术会议上，不应再讨论代码审查有什么好，为什么要做代码审查之类的问题。同时我接触过相当多所谓国内一线互联网公司，竟有许多是不做代码审查的，这一度让我颇为意外。
这里也不想多谈如何做好代码审查，只是就代码质量这点，不客气地说：没有过代码审查经历的同学，往往很难写出高质量的代码，尤其是在各种追求速度的糙快猛创业公司。
7. 静态检查
很多代码上的问题，都可以通过一些工具来找到，某些场景下，它比人要靠谱得多，至少不会出现某些细节上的遗漏，同时也能有效帮助大家减少代码审查的工作量。
Android开发中有Lint, Find bugs, PMD等优秀静态检查工具可用，通过改进这些工具找出的问题，就能对语法的细节，规范，编程的技巧有更多直观了解。
建议最好与持续集成(CI)，代码审查环境配套使用， 每次提交的代码都能自动验证是否通过了工具的代码检查，通过才允许提交。
8. 单元测试
Android单元测试，一直备受争议，主要还是原生的测试框架不够方便，每跑一次用例需要在模拟器或者真机上运行，效率太低，也不方便在CI环境下自动构建单元测试，好在有Robolectric，能帮我们解决部分问题。
单元测试的一个非常显著的优点是，当你需要修改大量代码时，尽管放心修改，只需要保证单元测试用例通过即可，无需瞻前顾后。
9. 充分自测
有一种说法：程序员最害怕的是他自己写的代码，尤其是准备在众人面前show自己的工作成果时，因此在写完代码后，需要至少跑一遍基本的场景，一些简单的异常流。在把你的工作成果提交给测试或用户前，充分自测是基本的职业素养，不要总想着让测试帮你找问题，随便用几下就Crash的东西，你好意思拿给别人吗？
10. 善用开源
并非开源的东西，质量就高，但至少关注度较高，使用人数较多，口碑较好的开源项目，质量是有一定保证的，这其中的道理很简单。即便存在一些问题，也可以通过提交反馈，不断改进。最重要的是，你自己花时间造的轮子，需要很多精力维护，而充分利用开源项目，能帮助你节省很多时间，把精力专注在最需要你关心的问题上。
2. 如何编写高质量的python程序
写出规范的代码是写出高质量代码的第一步，并且有助于培养仔细的习惯。
为了培养规范写代码的习惯，可以安装flake8这个工具，它不仅可以检查代码风格是否符合官方建议（PEP8），而且还能找出潜在的隐患（用Pyflakes做语法分析），更逆天的是还能检测到你有些函数写的太复杂（代码圈复杂度）了，更更逆天的是可以设置git commit之前必须通过这些检查。
当然具体操作需要根据自己的项目进行一些定制，比如可以忽略E501，W293。
空白项目模版
好的开始是成功的一半，写python代码就从pyempty开始吧。
在github上看一下那些经典的项目，web.py,flask, pep8，他们的项目目录都很规范，综合借鉴了一些项目的特点，我写了这个pyempty项目。
1.README.md 这里写你项目的简介，quick start等信息，虽然distutils要求这个文件没有后缀名，但github上如果后缀是.md的话可以直接转换成html显示。
2.ChangeLog.txt 该文件存放程序各版本的变更信息，也有一定的格式，参考web.py的ChangeLog.txt
3.LICENES.txt 这里存放你项目使用的协议，不要编写自己的协议。
4.requirements.txt 如果你的项目需要依赖其它的python第三方库，在这里一行一个写出来，可能pip install的时候能自动帮你安装
5.setup.py 安装脚本，后面详细介绍
6.docs 里面存放你的项目文档，如概要设计，详细设计，维护文档，pydoc自动生成的文档等，强烈推荐大家使用MarkDown格式编写文档
7.src 这个目录里存放项目模块的主要代码，尽量不要把模块目录直接放到根目录，模块代码目录可以在setup.py里指定的
8.tests 这个目录存放所有单元测试，性能测试脚本，单元测试的文件确保以test_做前缀，这样distutils会自动打包这些文件，并且用python -m unittest discover -s ./ -p 'test_*.py' -v 可以直接执行这些测试
单元测试
Martin Fowler："在你不知道如何测试代码之前，就不该编写程序。而一旦你完成了程序，测试代码也应该完成。除非测试成功，你不能认为你编写出了可以工作的程序。"
我们有很多理由不写单元测试，归根结底是懒，虽然代码大全上说：
大部分研究都发现，检测比测试的成本更小。NASA软件工程实验室的一项研究发现，阅读代码每小时能够检测出来的缺陷要比测试高出80%左右(Basili and Selby 1987)。后来，IBM的一项研究又发现，检查发现的一个错误只需要3.5个工作时，而测试则需要花费15-25个工作时（Kaplan 1995)。
但是单元测试还是让别人相信你的代码有很高质量的最有力证据。
好了，请详细阅读：
深入python3.0: 单元测试-2.x也适用
Unit testing framework 不完整中文版
文档
敏捷开发不是提倡什么文档也不写，没有文档就没有传承和积累，轮岗或新人接手任务就会遇到很大的麻烦，所以我决定每个项目最少要写以下文档：
1.nalysis.model.md 概要设计文档，不同于README.md文件，该文档应该写于项目开发之前，把项目有哪些功能，大概分几个模块等项目整体概述信息写一下。
2.design.model.md 详细设计文档，不用太详细，至少把项目依赖哪些东西，谁依赖这个项目，重要算法流程描述，代码整体结构等写出来。
3.maintain.md 维护文档，这个我觉得最重要，你的服务都记录哪些日志，需要监控哪些业务指标，如何重启，有哪些配置项等，没这些东西，你的项目很难运维。
上面这些文档都是项目全局性的文档，不适合写在docstring或注视里，所以要有单独的文档。
打包
python有专门的模块打包系统distutils，你可以用这套机制把你的代码打包并分发到Pypi上，这样任何人都可以用pip或easy_install安装你的模块。
如果你开发的是内部项目，还可以用mypypi架设私有的pypi，然后把项目的大的版本更新发布到内部的pypi上，配置管理人员和运维人员可以很方便的从pypi上拉取代码安装到测试环境或生产环境。
发布大版本的时候要给版本命名及编写ChangeList，可以参考Git Pro的相关章节,主要记住以下几个命令。
git tag -a v0.1 -m 'my test tag' #给大版本命名，打Tag
git describe master #给小版本命名,Git将会返回一个字符串，由三部分组成：最近一次标定的版本号，加上自那次标定之后的提交次数，再加上一段SHA-1值
git shortlog --no-merges master --not v0.1 #生成版本简报,ChangeList
python有自己的打包机制，所以一般不要用git archive命令。
当然大版本管理用pypi管理比较合适，小的bug fix，紧急上线等好多公司都是用git直接从生产环境拉代码更新，因为git,svn等可以很方便的撤销某次更新，回滚到某个位置。
如何管理好大版本上线和小的紧急上线，我还没理清思路，欢迎大家参与讨论。
关于打包，请阅读如下链接：
Python 打包指南
深入Python3.0:打包 Python 类库
python打包:分发指定文件
出自：http://developer.51cto.com/art/201209/356603.htm
3. 如何编写高质量的VB代码
1. 使用整数（Integer）和长整数（Long）
提高代码运行速度最简单的方法莫过于使用正确的数据类型了。也许你不相信，但是正确地选择数据类型可以大幅度提升代码的性能。在大多数情况下，程序员可以将Single，Double和Currency类型的变量替换为Integer或Long类型的变量，因为VB处理Integer和Long的能力远远高于处理其它几种数据类型。
在大多数情况下，程序员选择使用Single或Double的原因是因为它们能够保存小数。但是小数也可以保存在Integer类型的变量中。例如程序中约定有三位小数，那么只需要将保存在Integer变量中的数值除以1000就可以得到结果。根据我的经验，使用Integer和Long替代Single，Double和Currency后，代码的运行速度可以提高将近10倍。
2. 避免使用变体
对于一个VB程序员来说，这是再明显不过的事情了。变体类型的变量需要16个字节的空间来保存数据，而一个整数（Integer）只需要2个字节。通常使用变体类型的目的是为了减少设计的工4作量和代码量，也有的程序员图个省事而使用它。但是如果一个软件经过了严格设计和按照规范编码的话，完全可以避免使用变体类型。
在这里顺带提一句，对于Object对象也存在同样的问题。请看下面的代码：
Dim FSO
Set FSO = New Scripting.FileSystemObject
或
Dim FSO as object
Set FSO = New Scripting.FileSystemObject
上面的代码由于在申明的时候没有指定数据类型，在赋值时将浪费内存和CPU时间。正确的代码应该象下面这样：
Dim FSO as New FileSystemObject
3. 尽量避免使用属性
在平时的代码中，最常见的比较低效的代码就是在可以使用变量的情况下，反复使用属性（Property），尤其是在循环中。要知道存取变量的速度是存取属性的速度的20倍左右。下面这段代码是很多程序员在程序中会使用到的：
Dim intCon as Integer
For intCon = 0 to Ubound(SomVar())
Text1.Text = Text1.Text & vbcrlf & SomeVar(intCon)
Next intCon
下面这段代码的执行速度是上面代码的20倍。
Dim intCon as Integer
Dim sOutput as String
For intCon = 0 to Ubound(SomeVar())
sOutput = sOutput & vbCrlf &
SomeVar(intCon)
Next
Text1.Text = sOutput
4. 尽量使用数组，避免使用集合
除非你必须使用集合（Collection），否则你应该尽量使用数组。据测试，数组的存取速度可以达到集合的100倍。这个数字听起来有点骇人听闻，但是如果你考虑到集合是一个对象，你就会明白为什么差异会这么大。
5. 展开小的循环体
在编码的时候，有可能遇到这种情况：一个循环体只会循环2到3次，而且循环体由几行代码组成。在这种情况下，你可以把循环展开。原因是循环会占用额外的CPU时间。但是如果循环比较复杂，你就没有必要这样做了。
6. 避免使用很短的函数
和使用小的循环体相同，调用只有几行代码的函数也是不经济的--调用函数所花费的时间或许比执行函数中的代码需要更长的时间。在这种情况下，你可以把函数中的代码拷贝到原来调用函数的地方。
7. 减少对子对象的引用
在VB中，通过使用.来实现对象的引用。例如：
Form1.Text1.Text
在上面的例子中，程序引用了两个对象：Form1和Text1。利用这种方法引用效率很低。但遗憾的是，没有办法可以避免它。程序员唯一可以做就是使用With或者将用另一个对象保存子对象（Text1）。
注释： 使用With
With frmMain.Text1
.Text = "Learn VB"
.Alignment = 0
.Tag = "Its my life"
.BackColor = vbBlack
.ForeColor = vbWhite
End With
或者
注释： 使用另一个对象保存子对象
Dim txtTextBox as TextBox
Set txtTextBox = frmMain.Text1
TxtTextBox.Text = "Learn VB"
TxtTextBox.Alignment = 0
TxtTextBox.Tag = "Its my life"
TxtTextBox.BackColor = vbBlack
TxtTextBox.ForeColor = vbWhite 注意，上面提到的方法只适用于需要对一个对象的子对象进行操作的时候，下面这段代码是不正确的：
With Text1
.Text = "Learn VB"
.Alignment = 0
.Tag = "Its my life"
.BackColor = vbBlack
.ForeColor = vbWhite
End With
很不幸的是，我们常常可以在实际的代码中发现类似于上面的代码。这样做只会使代码的执行速度更慢。原因是With块编译后会形成一个分枝，会增加了额外的处理工作。
8. 检查字符串是否为空
大多数程序员在检查字符串是否为空时会使用下面的方法：
If Text1.Text = "" then
注释： 执行操作
End if
很不幸，进行字符串比较需要的处理量甚至比读取属性还要大。因此我建议大家使用下面的方法：
If Len(Text1.Text) = 0 then
注释： 执行操作
End if
9. 去除Next关键字后的变量名
在Next关键字后加上变量名会导致代码的效率下降。我也不知道为什么会这样，只是一个经验而已。不过我想很少有程序员会这样画蛇添足，毕竟大多数程序员都是惜字如金的人。
注释： 错误的代码
For iCount = 1 to 10
注释： 执行操作
Next iCount
注释： 正确的代码
For iCount = 1 to 10
注释： 执行操作
Next
10. 使用数组，而不是多个变量
当你有多个保存类似数据的变量时,可以考虑将他们用一个数组代替。在VB中，数组是最高效的数据结构之一。
11. 使用动态数组，而不是静态数组
使用动态数组对代码的执行速度不会产生太大的影响，但是在某些情况下可以节约大量的资源。
12. 销毁对象
无论编写的是什么软件，程序员都需要考虑在用户决定终止软件运行后释放软件占用的内存空间。但遗憾的是很多程序员对这一点好像并不是很在意。正确的做法是在退出程序前需要销毁程序中使用的对象。例如：
Dim FSO as New FileSystemObject
' 执行操作
' 销毁对象
Set FSO = Nothing
对于窗体，可以进行卸载：
Unload frmMain
或
Set frmMain = Nothing
13. 变长和定长字符串
从技术上来说，与变长字符串相比，定长字符串需要较少的处理时间和空间。但是定长字符串的缺点在于在很多情况下，你都需要调用Trim函数以去除字符串末的空字符，这样反而会降低代码效率。所以除非是字符串的长度不会变化，否则还是使用变长字符串。
14. 使用类模块，而不是ActiveX控件
除非ActiveX控件涉及到用户界面，否则尽量使用轻量的对象，例如类。这两者之间的效率有很大差异。
15. 使用内部对象
在涉及到使用ActiveX控件和DLL的时候，很多程序员喜欢将它们编译好，然后再加入工程中。我建议你最好不要这样做，因为从VB连接到一个外部对象需要耗费大量的CPU处理能力。每当你调用方法或存取属性的时候，都会浪费大量的系统资源。如果你有ActiveX控件或DLL的源代码，将它们作为工程的私有对象。
16. 减少模块的数量
有些人喜欢将通用的函数保存在模块中，对于这一点我表示赞同。但是在一个模块中只写上二三十行代码就有些可笑了。如果你不是非常需要模块，尽量不要使用它。这样做的原因是因为只有在模块中的函数或变量被调用时，VB才将模块加载到内存中；当VB应用程序退出时，才会从内存中卸载这些模块。如果代码中只有一个模块，VB就只会进行一次加载操作，这样代码的效率就得到了提高；反之如果代码中有多个模块，VB会进行多次加载操作，代码的效率会降低。
17. 使用对象数组
当设计用户界面时，对于同样类型的控件，程序员应该尽量使用对象数组。你可以做一个实验：在窗口上添加100个PictureBox，每个PictureBox都有不同的名称，运行程序。然后创建一个新的工程，同样在窗口上添加100个PictureBox，不过这一次使用对象数组，运行程序，你可以注意到两个程序加载时间上的差别。
18. 使用Move方法
在改变对象的位置时，有些程序员喜欢使用Width，Height，Top和Left属性。例如：
Image1.Width = 100
Image1.Height = 100
Image1.Top = 0
Image1.Left = 0
实际上这样做效率很低，因为程序修改了四个属性，而且每次修改之后，窗口都会被重绘。正确的做法是使用Move方法：
Image1.Move 0,0,100,100
19. 减少图片的使用
图片将占用大量内存，而且处理图片也需要占用很多CPU资源。在软件中，如果可能的话，可以考虑用背景色来替代图片--当然这只是从技术人员的角度出发看这个问题。
20. 使用ActiveX DLL，而不是ActiveX控件
如果你设计的ActiveX对象不涉及到用户界面，使用ActiveX DLL。
编译优化
我所见过的很多VB程序员从来没有使用过编译选项，也没有试图搞清楚各个选项之间的差别。下面让我们来看一下各个选项的具体含义。
1. P-代码（伪代码）和本机代码
你可以选择将软件编译为P-代码或是本机代码。缺省选项是本机代码。那什么是P-代码和本机代码呢？
P-代码：当在VB中执行代码时，VB首先是将代码编译为P-代码，然后再解释执行编译好的P-代码。在编译环境下，使用这种代码要比本机代码快。选择P-代码后，编译时VB将伪代码放入一个EXE文件中。
本机代码：本机代码是VB6以后才推出的选项。当编译为EXE文件后，本机代码的执行速度比P-代码快。选择本机代码后，编译时VB使用机器指令生成EXE文件。
在使用本机代码进行编译时，我发现有时候会引入一些莫名其妙的错误。在编译环境中我的代码完全正确地被执行了，但是用本机代码选项生成的EXE文件却不能正确执行。通常这种情况是在卸载窗口或弹出打印窗口时发生的。我通过在代码中加入DoEvent语句解决了这个问题。当然出现这种情况的几率非常少，也许有些VB程序员从来没有遇到过，但是它的确存在。
在本机代码中还有几个选项：
a) 代码速度优化：该选项可以编译出速度较快的执行文件，但执行文件比较大。推荐使用
b) 代码大小优化：该选项可以编译出比较小的执行文件，但是以牺牲速度为代价的，不推荐使用。
c) 无优化：该选项只是将P-代码转化为本机代码，没有做任何优化。在调试代码时可以使用。
d) 针对Pentium Pro优化：虽然该项不是本机代码中的缺省选项，但是我通常会使用该选项。该选项编译出的可执行程序在Pentium Pro和Pentium 2以上的机器上可以运行得更快，而在比较老的机器上要稍稍慢一些。考虑到现在用Pentium 2都是落伍，所以推荐大家使用该选项。
e) 产生符号化调试信息：该项在编译过程中生成一些调试信息，使用户可以利用Visual C++一类的工具来调试编译好的代码。使用该选项会生成一个.pdf文件，该文件记录了可执行文件中的标志信息。当程序拥有API函数或DLL调用时，该选项还是比较有帮助的。
2. 高级优化
高级优化中的设置可以帮助你提高软件的速度，但是有时候也会引入一些错误，因此我建议大家尽量小心地使用它们。如果在代码中有比较大的循环体或者复杂的数学运算时，选中高级优化中的某些项会大幅度提升代码的性能。如果你使用了高级优化功能，我建议你严格测试编译好的文件。
a) 假定无别名：可以提高循环体中代码的执行效率，但是在如果通过变量的引用改变变量值的情况下，例如调用一个方法，变量的引用作为方法的参数，在方法中改变了变量的值的话，就会引发错误。有可能只是返回的结果错误，也有可能是导致程序中断运行的严重错误。
b) 取消数组绑定检查、取消整数溢出检查和取消浮点错误检查：在程序运行时，如果通过这些检查发现了错误，错误处理代码会处理这些错误。但是如果取消了这些检查，发生了错误程序就无法处理。只有当你确定你的代码中不会出现上面的这些错误时，你才可以使用这些选项。它们将使软件的性能得到很大的提升。
c) 允许不舍入的浮点操作：选择该选项可以是编译出来的程序更快地处理浮点操作。它唯一的缺点就是在比较两个浮点数时可能会导致不正确的结果。
d) 取消Pentium FDIV安全检查：该选项是针对一些老的Pentium芯片设置的，现在看来已经过时了。
4. 如何编写高质量的代码！
载选<编程思想>
非程序员 编 著
代码永远会有BUG，在这方面没有最好只有更好。高效是程序员必须作到的事情，无错是程序员一生的追求。复用、分而治之、折衷是代码哲学的基本思想。模块化与面向对象是实现高效无错代码的方法。高效无错代码需要思想与实践的不断反复。
1.2.1 命名约定
命令规范基本上采用了微软推荐的匈牙利命名法，略有简化。
1． 常量
常量由大写字母和数字组成，中间可以下划线分隔，如 CPU_8051。
2． 变量
变量由小写（变量类型）字母开头，中间以大写字母分隔，可以添加变量域前缀（变量活动域前缀以下划线分隔）。如： v_nAcVolMin（交流电压最小值）。
变量域前缀见下表
局部变量，如果变量名的含义十分明显，则不加前缀，避免烦琐。如用于循环的int型变量 i,j,k ；float 型的三维坐标（x,y,z）等。
3． 函数名一般由大写字母开头，中间以大写字母分隔，如SetSystemPara。函数命名采用动宾形式。如果函数为最底层，可以考虑用全部小写，单词间采用带下划线的形式。如底层图形函数：pixel、lineto以及读键盘函数get_key 等。
4． 符号名应该通用或者有具体含义，可读性强。尤其是全局变量，静态变量含义必须清晰。C++中的一些关键词不能作为符号名使用，如class、new、friend等。符号名长度小于31个，与ANSI C 保持一致。命名只能用26个字母，10个数字，以及下划线‘_’来组成，不要使用‘$’‘@’等符号。下划线‘_’使用应该醒目，不能出现在符号的头尾，只能出现在符号中间，且不要连续出现两个。
5． 程序中少出现无意义的数字，常量尽量用宏替代。
1.2.2 使用断言
程序一般分为Debug版本和Release版本，Debug版本用于内部调试，Release版本发行给用户使用。
断言assert是仅在Debug版本起作用的宏，它用于检查“不应该”发生的情况。以下是一个内存复制程序，在运行过程中，如果assert的参数为假，那么程序就会中止（一般地还会出现提示对话，说明在什么地方引发了assert）。
//复制不重叠的内存块
void memcpy(void *pvTo, void *pvFrom, size_t size)
{
void *pbTo = (byte *) pvTo;
void *pbFrom = (byte *) pvFrom;
assert( pvTo != NULL && pvFrom != NULL );
while(size - - > 0 )
*pbTo + + = *pbFrom + + ;
return (pvTo);
}
assert不是一个仓促拼凑起来的宏，为了不在程序的Debug版本和Release版本引起差别，assert不应该产生任何副作用。所以assert不是函数，而是宏。程序员可以把assert看成一个在任何系统状态下都可以安全使用的无害测试手段。
以下是使用断言的几个原则：
1）使用断言捕捉不应该发生的非法情况。不要混淆非法情况与错误情况之间的区别，后者是必然存在的并且是一定要作出处理的。
2）使用断言对函数的参数进行确认。
3）在编写函数时，要进行反复的考查，并且自问：“我打算做哪些假定？”一旦确定了的假定，就要使用断言对假定进行检查。
4）一般教科书都鼓励程序员们进行防错性的程序设计，但要记住这种编程风格会隐瞒错误。当进行防错性编程时，如果“不可能发生”的事情的确发生了，则要使用断言进行报警。
1.2.3 优化／效率
规则一：对于在中断函数／线程和外部函数中均使用的全局变量应用volatile定义。例如：
volatile int ticks;
void timer(void) interrupt 1 //中断处理函数
{
ticks++
}
void wait(int interval)
{
tick=0;
while(tick<interval);
}
如果未用volatile，由于while循环是一个空循环，编译器优化后（编译器并不知道此变量在中断中使用）将会把循环优化为空操作！这就显然不对了。
规则二：不要编写一条过分复杂的语句，紧凑的C++/C代码并不见到能得到高效率的机器代码，却会降低程序的可理解性，程序出错误的几率也会提高。
规则三：变量类型编程中应用原则：尽量采用小的类型（如果能够不用“Float”就尽量不要去用）以及无符号Unsigned类型，因为符号运算耗费时间较长；同时函数返回值也尽量采用Unsigned类型，由此带来另外一个好处：避免不同类型数据比较运算带来的隐性错误。
1.2.4 其他
规则一：不要编写集多种功能于一身的函数，在函数的返回值中，不要将正常值和错误标志混在一起。
规则二：不要将BOOL值TRUE和FALSE对应于1和0进行编程。大多数编程语言将FALSE定义为0，任何非0值都是TRUE。Visual C++将TRUE定义为1，而Visual Basic则将TRUE定义为-1。例如：
BOOL flag;
…
if(flag) { // do something } // 正确的用法
if(flag==TRUE) { // do something } // 危险的用法
if(flag==1) { // do something } // 危险的用法
if(!flag) { // do something } // 正确的用法
if(flag==FALSE) { // do something } // 不合理的用法
if(flag==0) { // do something } // 不合理的用法
规则三：小心不要将“= =”写成“=”，编译器不会自动发现这种错误。
规则四：建议统一函数返回值为无符号整形，0代表无错误，其他代表错误类型。
1.3 模块化的C编程
C语言虽然不具备C++的面向对象的成分，但仍应该吸收面向对象的思想，采用模块化编程思路。面向对象的思想与面向对象的语言是两个概念。非面向对象的语言依然可以完成面向对象的编程，想想C++的诞生吧！
C++没有理由对C存在傲慢与偏见，不是任何场合C++方法都是解决问题的良药，譬如面对嵌入式系统效率和空间的双重需求。注意我们谈的是方法，而不是指编译器。
C在软件开发上存在的首要问题是缺乏对数据存取的控制（封装），C编程者乐而不疲的使用着大量extern形式的全局变量在各模块间交换着数据，“多方便啊”编程者乐曰，并传授给下一个编程者。这样多个变量出现在多个模块中，剪不断理还乱，直到有一天终于发现找一个“人”好难。一个东西好吃，智者浅尝之改进之，而愚者只会直至撑死。
这世上本没有什么救世主，应在C上多下功夫，程序员和C缔造者早就有过思考，相信野百合也有春天，还是看看C语言如何实现模块化编程方法，在部分程度上具备了OO特性封装与多态。
在具体阐述之前，需要明确生存期与可见性的概念。生存期指的是变量在内存的生存周期，可见性指的是变量在当前位置是否可用。两者有紧密联系，但不能混为一谈。一个人存在但不可见只能解释成上帝或灵魂，一个变量存在但不可见却并非咄咄怪事，模块化方法正是利用了静态函数、静态变量这些“精灵”们特殊的生存期与可见性。
最后需要明确一点的是这里的模块是以一个.C文件为单位。
规则一：利用函数命名规则和静态函数
模块中不被其他模块调用的内部函数采用以下命名规则：用全部小写，单词间采用带下划线的形式。如底层图形函数：pixel、lineto以及读键盘函数get_key等。这些函数应定义为static静态函数，这样在其他模块错误地调用这些函数时编译器能给出错误（如BC编译器）。（注意：有些编译器不能报告错误，但为了代码风格一致和函数层次清晰，仍建议这样作）。
规则二：利用静态变量
模块中不能被其他模块读写的全局变量应采用static声明，这样在其他模块错误地读写这些变量时编译器能给出警告（C51编译器）或错误（BC编译器）。
规则三：引入OO接口概念和指针传参
模块间的数据接口（也就是函数）应该事先较充分考虑，需要哪些接口，通过接口需要操作哪些数据，尽量作到接口的不变性。
模块间地数据交换尽量通过接口完成，方法是通过函数传参数，为了保证程序高效和减少堆栈空间，传大量参数（如结构）应采用传址的方式，通过指针作为函数参数或函数返回指针，尽量杜绝extern形式的全局变量，请注意是extern形式的全局变量，模块内部的全局变量是允许和必须的。
传指针参数增加的开销主要是作参数的指针和局部指针的数据空间（嵌入式系统（如C51）往往由于堆栈空间有限，函数参数会放到外部RAM的堆栈中），增加的代码开销仅是函数的调用，带来的是良好的模块化结构，而且使用接口函数会比在代码中多处直接使用全局变量大大节约代码空间。
需注意一点的事物总有他的两面性，水能载舟，也能覆舟。对于需要频繁访问的变量如果仍采用接口传递，函数调用的开销是巨大的，这时应考虑仍采用extern全局变量。
以下演示了两个C模块交换数据：
//Mole1.C
OneStruct* void GetOneStruct(void); //获取模块1数据接口
void SetOneStruct(OneStruct* pOneStruct); //写模块1数据接口
struct OneStruct
{
int m¬_imember；
//……
}t1; //模块1的数据
//t1初始化代码…..
OneStruct* void GetOneStruct(void)
{
OneStruct* pt1; //只需定义一个局部变量
t1.imember=15;
pt1=&t1;
return pt1;
}
void SetOneStruct(OneStruct* pOneStruct)
{
t1.imember=pOneStruct->imember;
//…….
}
//Mole2.C
void OperateOneStruct(void); //模块2通过模块1提供的接口操作模块1的数据
OneStruct* void GetOneStruct(void);
void SetOneStruct(OneStruct* pOneStruct);
void OperateOneStruct(void)
{
OneStruct* pt2; //只需定义一个局部变量
pt2=GetOneStruct(); //读取数据
SetOneStruct(pt2); //改写数据
}
采用接口访问数据可以避免一些错误，因为函数返回值只能作右值，全局变量则不然。
例如 cOneChar == 4; 可能被误为cOneChar = 4;
规则四：有限的封装与多态
不要忘记C++的class源于C的struct，C++的虚函数机制实质是函数指针。为了使数据、方法能够封装在一起，提高代码的重用度，如对于一些与硬件相关的数据结构，建议采用在数据结构中将访问该数据结构的函数定义为结构内部的函数指针。这样当硬件变化，需要重写访问该硬件的函数，只要将重写的函数地址赋给该函数指针，高层代码由于使用的是函数指针，所以完全不用动，实现代码重用。而且该函数指针可以通过传参数或全局变量的方式传给高层代码，比较方便。例如：
struct OneStruct
{
int m¬_imember；
int (*func)(int,int);
//……
}t2;