|
EDA365欢迎您登录!
您需要 登录 才可以下载或查看,没有帐号?注册
x
本帖最后由 多言数穷 于 2019-12-27 10:18 编辑
+ I; p7 |' r' M9 D& ^9 R. `/ F% p; o* \- a
0.1前言3 S2 \( {& H/ S
为提高产品代码质量,指导广大软件开发人员编写出简洁、可维护、可靠、可测试、高效、可移植的
+ q9 g" [- r9 I! Y$ O X5 S3 C1 x9 X代码,编程规范修订工作组分析、总结了我司的各种典型编码问题,并参考了业界编程规范近年来的- C( b0 P* \% Q9 w5 b$ z
成果,重新对我司1999年版编程规范进行了梳理、优化、刷新,编写了本规范。 f, t: {$ T; N6 q) }! B g
本规范将分为完整版和精简版,完整版将包括更多的样例、规范的解释以及参考材料(what & why) ,
4 A# f3 i5 o, `# s! K5 [而精简版将只包含规则部分(what)以便查阅。
" U9 [5 D7 l7 e& b在本规范的最后,列出了一些业界比较优秀的编程规范,作为延伸阅读参考材料。
4 ]! ^0 d- E6 X- _; S0.2代码总体原则
- c5 M3 |9 c& `7 h1、清晰第一7 H3 F$ V+ z( ^, a2 Q$ R3 m
清晰性是易于维护、易于1构的程序必需具备的特征。代码首先是给人读的,好的代码应当可以像文
7 o$ s' _* j4 f T章- -样发声朗诵出来。: J1 n. o V9 ~3 T R( a' h" L2 V
目前软件维护期成本占整个生命周期成本的40% ~90%。根据业界经验,维护期变更代码的成本,小型系
! P1 s- j$ @! y8 U k统是开发期的5倍,大型系统(100万行代码以上)可以达到100倍。业界的调查指出,开发组平均大约
. v# S! s2 h8 B一半的人力用于弥补过去的错误,而不是添加新的功能来帮助公司提高竞争力。5 ` W- y( V0 _9 i! O; n
“程序必须为阅读它的人而编写,只是顺便用于机器执行。”.一Harold Abelson和Gerald Jay
7 d; s' b9 e/ ?" y& o' XSussman& u5 U0 s, h) V
“编写程序应该以人为本,计算机第二。”一-Steve McConnell
" K2 o' V. F+ b2 C$ e4 a本规范通过后文中的原则(如头优秀的代码可以自我解释,不通过注释即可轻易读懂/头文件中适合放% [+ V4 t' J8 y& X$ [
置接口的声明,不适合放置实现/除了常见的通用缩写以外,不使用单词缩写,不得使用汉语拼音)、9 J# M: b- ^; L, Y9 [9 r) F6 K0 @' q
规则(如防止局部变量与全局变量同名)等说明清晰的重要性。0 W/ b) g! m% ^7 q2 H7 |
- -般情况下,代码的可阅读性高于性能,只有确定性能是瓶颈时,才应该主动优化。 j% ~; U( K' u5 r; R/ w- Z4 X5 d
2、简洁为美
8 ?9 ~/ M9 t( o* r3 f3 u简洁就是易于理解并且易于实现。代码越长越难以看懂,也就越容易在修改时引入错误。写的代码越1 a9 c8 |# \- H2 ^
多,意味着出错的地方越多,也就意味着代码的可靠性越低。因此,我们提倡大家通过编写简洁明了& }3 a6 h& M1 {4 L$ U
的代码来提升代码可靠性。
5 X8 P" i: M+ u6 S废弃的代码(没有被调用的函数和全局变量)要及时清除,重复代码应该尽可能提炼成函数。
4 q7 I# s. y3 L: F* N3 [, a8 G本规范通过后文中的原则(如文件应当职责单- -/-一个函数仅完成一-件功能) 、规则(重复代码应该尽
7 S8 J+ @8 A7 l: `- p6 _. Z# g可能提炼成函数/避免函数过长,新增函数不超过50行)等说明简洁的重要性。% S' Z3 J# C" I% C1 f
|
|