编码规范很重要，其实他直接影响到了代码迭代更新的效率和出问题的概率。以下为本人对 上广为流传的华为编码规范的个人总结。（ps:其中有几个原则实在是精辟的不能再精辟了，当然也有一些存在疑惑，还希望各位大佬不吝赐教）
1.不要使用难懂的技巧性很高的语句，除非很有必要时
高技巧语句不等于高效率的程序，实际上程序的效率关键在于算法。这可能是很多初学者最容易犯得错误。
2.去掉没必要的公共变量
公共变量是增大模块间耦合的原因之一。全局变量虽然好用，但是宜少不宜多这样能保证数据的安全性。
3.当向公共变量传递数据时，最好做数据合法性检查。
有必要最好做一下，因为万一出了问题是不好检测出来的。
4.构造仅有一个模块或函数可以修改、创建，而其余有关模块或函数只访问的公共变量，
防止多个不同模块或函数都可以修改、创建同一公共变量的现象
还是前面讲到的数据安全性问题，可以通过静态函数实现，且整个系统都要保持一致
5.仔细设计结构中元素的布局与排列顺序， 使结构容易理解、 节省占用空间， 并减少引起
误用现象
6.尽量减少没有必要的数据类型默认转换与强制转换。
7.对所调用函数的错误返回码要仔细、全面地处理
Linux系统里好像是不允许有空函数的
8.防止将函数的参数作为工作变量
将函数的参数作为工作变量， 有可能错误地改变参数内容， 所以很危险。 对必须改
变的参数，最好先用局部变量代之，最后再将该局部变量的内容赋给该参数。
9.一个函数仅完成一件功能。
10.避免设计多参数函数，不使用的参数从接口中去掉。
目的减少函数间接口的复杂度，参数多的话可以通过结构体实现
11.非调度函数应减少或防止控制参数，尽量只使用数据参数
避免函数功能不明确，给调试带来麻烦
12.检查函数所有参数输入的有效性
功能不明确较小的函数，特别是仅有一个上级函数调用它时， 应考虑把它合并到上级
函数中， 而不必单独存在
13.设计高扇入、 合理扇出（小于7） 的函数。
函数较合理的扇出（调度函数除外） 通常是 3-5.较良好的软件结构通常是顶层函数的扇出较高， 中层函数的扇出较少， 而底层函数则扇入到公共模块中。还是强调函数的高复用性和可读性
14.避免使用BOOL参数
TURE/FALSE 的含义是非常模糊的，这点确实有点惊讶，对于那些内存要求不是很苛刻的能不用就不用吧
15.对于提供了返回值的函数， 在引用时最好使用其返回值。
16.当一个变量名较长且有较多引用时（一般是结构的成员）， 可以用一个
意义相当的宏代替
也可以定义一个局部变量，在用之前对局部变量赋值
17.在同一项目组或产品组内， 调测打印出的信息串的格式要有统一的形式。 信息串中至少
要有所在模块名（或源文件名） 及行
行 和文件名可以用宏__LINE__和__FILE__实现
18.使用断言来发现软件问题， 提高代码可测性。
断言可以对在系统中隐藏很深， 用其它手段极难发现的问题进行定位
19.在编写代码之前， 应预先设计好程序调试与测试的方法和手段， 并设计好各种调测开关
及相应测试代码如打印函数等
20.在保证软件系统的正确性、 稳定性、可读性及可测性的前提下， 提高代码效率。
21.避免循环体内含判断语句， 应将循环语句置于判断语句的代码块之中
笔者确实踩过这样的坑，并且真的很难发现是什么问题。另外循环嵌套尽量不要超过三层且不要太复杂。
22.尽量用乘法或其它方法代替除法，特别是浮点运算中的除法。
浮点运算除法要占用较多 CPU 资源。应为一般的cpu只有硬件乘法器
23.过程/函数中申请的（为打开文件而使用的）文件句柄，在过程/函数退出之前要关闭。
分配的内存不释放以及文件句柄不关闭， 是较常见的错误， 而且稍不注意就有可能发生。这类错误往往会引起很严重后果，且难以定位
24.有可能的话， if语句尽量加上else分支， 对没有else分支的语句要小心对待； switch
语句必须有default分支。
25.时刻注意表达式是否会上溢、 下溢。
26.打开编译器的所有警告开关对程序进行编译
27.某些语句经编译后产生警告，但如果你认为它是正确的，那么应通过某种手段去掉告
警信息
28.使用代码检查工具（如C语言用PC-Lint）对源程序检查。使用软件工具（如 LogiSCOPE）进行代码审查
用过其中一个，效果不理想可能是不会用吧
29.不应通过“试” 来解决问题，应寻找问题的根本原因。
最精辟的原则之一，可很多人就是通过“试”
30.对自动消失的错误进行分析，搞清楚错误是如何消失的
最精辟的原则之一，对于提高能力有很大帮助
骗阅览量链接：
编码规范——NASA篇
文章知识点与官方知识档案匹配，可进一步学习相关知识C技能树首页概览115788 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！