编程注意事项
程序不仅需要给计算机读,也要给程序员读。程序设计风格的原则,代码应该清楚的和简单的,具有直截了当的逻辑,自然的表达式,通行的语言使用方式,有意义的名字和帮助作用和注释。

一 名字

1.   全局变量命名使用说明性的名字,局部变量用短名字
2.   保持名字的清晰可读和一致性
3.   函数采用动作性名字,要准确
4.   对于变量命名，禁止取用单个字符。（做局部循环变量除外）
5.   一般命名采用全小写加下划线或大小写混排的方式，不要使用既有大小写又有下划线的命名方式。
6.   除非必要，不要用数字或较奇怪的字符来定义标志符。即变量、函数、宏命名只能由26个字母，及下划线的一个子集来组成，不能使用"＄"等特殊符号。
7.   在同一软件产品内，应规划好接口部分的标志符（变量、常量、结构、函数）的命名，
防止编译、链接时产生错误冲突。
8.   自定义类型名以大写字母开头，各单词之间以大写字母分隔，如CallType（即骆驼式命名法）。变量名以小写字母开头，各单词之间以大写字母 分隔（变量活动范围前缀以下划线分隔），如m_pReleaseIn。函数名以大写字母开头，各单词之间以大写字母分隔（进程、进程页及子函数前缀以下划 线分隔），如Sub_ErrorDealing。
9.   变量名以小写的变量类型指示符（或类型组合）作为前缀开头，（即匈牙利式命名法与骆驼式命名法的结合）常用类型前缀列表如下：
   p       : pointer
   bit      : bit 型变量
   b       : unsigned char 或 BYTE
   w       : unsigned short 或 WORD
   dw      :unsigned long 或DWORD
   str      : 字符串
   以上前缀可以进一步组合成新的类型，自定义的数据类型可以自己规定类型前缀，如果该类型使用较为广泛，可以统一规定为我公司内部的通用前缀。
10.   符号名长度应大于等于2个字节，增加程序的可读性。循环语句（如FOR、WHILE、DO等）中的计数器可采用ii、jj等代替i、j，以避免出现例外最容易上手的编程语言
11.   下划线符号'_'不要出现在符号名的开始或结尾，因为这类符号名不够醒目，容易与不带下划线'_'的符号名混淆（条件编译例外，且只能用两个 下划线）。一个符号名中间不应出现连续两个'_'，因为两个'_'与一个'_'之间的区别不明显，容易混淆（条件编译的前后下划线例外，且只能用两个下划 线，中间下划线不能用连续两个'_'）。
12.   命名宏定义时，表示最大个数时定义为XXX_MAX_NUM（如最大子节点个数可用SNODE_MAX_NUM表示），表示最大取值时定义为 XXX_MAX（如PT板E1的最大取值可用PT_E1_MAX表示）。定义最小个数时定义为XXX_MIN_NUM，定义最小取值时定义为 XXX_MIN。（以防止下标使用时难以分辨是否需要减1）。


二 一致性和语句，表达式

1．   程序块要采用缩进风格编写
2．   相对独立的程序块之间、变量说明之后必须加空行。
3．   较长的语句要分多行书写，在低优先级操作符处划分新行，操作符放在新行之首。划分出的新行进行适当的缩进。
4．   循环、判断等语句中有较长的表达式或语句，要进行适当的划分，在低优先级操作符处划分新行，操作符放在新行之首。
5．   一行只写一条语句。
6．   尽量不使用goto语句；除了错误处理跳转
7．   函数或过程中的参数较长，则要进行适当的划分。
8．   函数体内所有内部变量必须在函数开始部分
9．   程序和注释行不要超过70列
10．   函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格，case语句下的情况也要遵从语句缩进要求。
11．   函数必须在开始部分写明缺省的返回值
12．   程序和注释行不要超过70列
13．   不要太相信函数的调用者,在内部要作好检查和保护
14．   当向公共变量传递数据时，应十分小心，防止赋予不合理的值或越界等现象发生。
15．   对于动态数组和字符串要使用标准函数对长度进行检查
16．   模块声明顺序: 常量-变量-事件-外部函数和过程-属性-方法过程;公共-友元-私有
 
三  注释
1.   一般情况下，注释必须与其上面的代码用空行隔开。
2.   说明文件（如.件、.inc文件、.def文件、编译说明文件　.cfg　等）头部应进行注释，注释必须列出：版权说明、版l本号、生成日期、作者、内容、功能、与其他文件的关系、修改日志等，头文件的注释中还应有函数功能简要说明。
3.   源文件头部应进行注释，注释必须列出：版权说明、版本号、生成日期、作者、模块目的／功能、主要函数及其功能、修改日志等。
4.   函数头部应进行注释，列出；函数的目的／功能、输入输出参数、返回值、调用关系、（函数、表）等。
5.   边写代码边注释，修改代码的同时修改注释，以保证代码与注释的一致性。删除不再有用的注释。
6.   注释的内容要清楚、明了、含义准确，防止注释二义性,尽量说明原因、代码作用及后果。
7.   避免在注释中使用缩写。
8.   注释应与其描述的代码相近，对代码的注释应放在其上方或右方相邻位置，不可放在下面，放于上方应与其上面的代码用空行隔开。
9.   对于所有有物理含义的变量、常量，如果其命名不是充分自注释的，在声明时必须加注释说明其含义。
10.   数据结构声明（包括数组、结构、类、枚举等），如果其命名不是充分自注释的必须加以注释。对数据结构的注释应放在其上方相邻位置，不可放在下面；结构中的每个域的注释放在其右方。
11.   全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明。
12.   注释要和所注释的内容进行同样的缩排。
13.   对于switch语句下的case语句，如果因为特殊情况需要处理完一个case后进入下一个case处理，必须在case处理完、下一个case语句前加上明确的注释。
14.   避免在一行代码或表达式的中间插入注释。
15.   通过对函数或过程、变量、结构等正确的命名以及合理地组织代码的结构，使代码成为自注释的。
16.   在代码的功能、意图层次上进行注释，提供额外、有用的信息。
17.   在程序块的结束行右方加注释标记，以表明某程序块的结束。
18.   注释尽量使用中文。
19.   源文件中必须有被调用函数显示的函数原型说明。
20.   当函数复杂时应说明其算法

四  变量使用
1.   申明过的变量必须被使用，没有被使用的变量应从程序中取消。
2.   明确公共变量与操作此公共变量的函数或过程的关系，如访问、修改、及创建等。
3.   防止局部变量与公共变量同名
4.   结构的功能要单一，是针对一种事务的抽象。
5.   不同结构间的关系不要过于复杂。
6.   结构中元素的个数应适中。若结构中元素个数过多可考虑依据某种原则把元素组成不同的子结构，以减少原结构中元素的个数。
7.   仔细设计结构中元素的布局与排列顺序，使结构容易理解、节省占用空间、减少误用的可能。
8.   全局变量不能作为函数的参数。
9.   对于动态创建的数据对象必须在相应程序释放
10.   要显示地动态创建对象,不要使用AS NEW 方式定义
11.   对自定义数据类型进行恰当命名，使它成为自描述性的，以提高代码的可读性。注意命名方式在同一产品中的统一。

五 函数,过程
1.   对于调用函数的错误返回码 要进行仔细、全面的处理。
2.   明确函数的功能，精确（而不是近似）地实现函数设计。
3.   编写可重入函数时，应注意局部变量的使用。
4.   编写可重入函数时，若使用全局变量，则应通过关中断、信号量等手段对其加以保护。
5.   防止将函数的参数作为工作变量。
6.   函数的规模尽量控制在200行以内。
7.   一个函数仅完成一个功能。
8.   简单的功能也要编写一个函数表示。
9.   不要设计多用途、面面俱到的函数。
10.   函数的功能应该是可以预测的，即输入相同时，输出也应该相同。
11.   尽量不要编写依赖于其他函数内部实现的函数。
12.   避免设计多参数函数，不使用的参数从接口中去掉。
13.   非调度函数应防止或减少控制参数，尽量只使用数据参数。
14.   检查函数所有参数输入的有效性。
15.   检查函数所有非参数输入的有效性，如数据文件、公共变量等。
16.   函数名应准确描述函数的功能。
17.   使用动宾词组为执行某操作的函数命名。避免使用无意义的或含义不清的动词为函数命名。
18.   函数的返回值要清楚、明了，让使用者不容易忽视错误情况。
19.   除非必要，最好不要以编译系统默认的转换方式或强制的转换方式把与函数返回值类型不同的变量作为返回值返回。
20.   让函数在调用点显得易懂、容易理解。在调用函数填写参数时，应尽量减少没有必要的默认数据类型转换方式或强制的数据类型转换方式。
21.   去除函数中不必要的语句，防止程序中的垃圾代码。
22.   防止把没有关联的语句放到一个函数中。
23.   注意函数划分上的问题，如应该防止多段代码重复做同一件事。
24.   功能不明确、较小的函数，特别是只有一个上级函数调用它时，应考虑把它合并到上一级函数中，不必单独存在。
25.   不使用函数本身或函数间的递归调用。
26.   仔细分析模块的功能及性能需求，并进一步细分，若有必要画出数据流程图，据此来进行模块的函数划分与组织。
27.   优化模块中函数的结构，降低函数间的耦合度，并提高函数的独立性，代码的可读性、效率和可维护性。优化遵守以下原则：
（1）不能影响模块功能的实现（2）仔细考查模块或函数的出错处理及模块的性能要求并
进行完善（3）通过分解或合并函数来改进软件结构，考查函数的规模， 过大的要进行分解（4）设法降低函数间接口的复杂度（5）不同层次的函数调用要有合理的扇入和扇出（6）提高函数内聚（7）函数功能应可预测
28.   在多任务操作系统的环境下编程，应注意函数可重入性的构造。
29.   函数的嵌套深度限制在5级以内，以增加程序的可读性，并减少出错的危险。
30.   函数的所有参数都应该在函数体内被使用，以减少错误（建议）。
31.   调用具有返回值的函数时，必须判断返回的结果，并根据返回值作相应处理（建议）。
32.   函数的参数表中所有参数的总长度不能大于40个字节，一些自定义的结构参量可以采用传递指针的方式进行参数传递，这样可以减少函数调用对系统堆栈的需求，同时防止因堆栈溢出引起的软件故障（建议）。


六 可测性

1.   在同一项目组或产品组内，要有一套统一的为集成测试与系统联调准备的调测开关及相应打印函数，并要有详细说明。
2.   在同一项目组或产品组内，调测打印出的信息串的格式要有统一规定的形式，信息串中至少要有所在模块名（或源文件名）及行号。
3.   编程的同时要为单元测试选择恰当的测试点，并仔细构造测试代码、测试用例，同时给出明确的注释说明。测试代码部分应作为一个子模块，以方便测试代码在模块中的安装与拆卸（通过调测开关）。
4.   在进行集成测试/系统联调之前，要构造好测试环境、测试项目及测试用例，同时仔细分析并优化测试用例，以提高测试效率。
5.   断言设置：断言是在调试版本中使用的一种条件判断，它表示程序执行到某一点时必须满足的条件，若条件不满足则引起程序中断。而在正式版本中断言以空语句代替。
6.   前束断言：在函数的人口处应设置前束断言，对本函数输入参数在正常运行时不可能出现的情况做断言检查；该断言主要用于在调试版本中尽早暴露函数调用者的错误。
7.   后束断言：在函数的出口处设置后束断言，对本函数返回值在正常运行时不可能出现的情况做断言检查；该断言主要用于在调试版本中尽早暴露函数处理过程中的错误。
8.   循环不变式：在各种可变条件循环中，对在循环过程中应满足的条件作断言检查；该断言主要用于在调试版本中检查循环的合法性和数据结构的完整性；（建议）
9.   使用断言来发现软件问题，提高代码可测性。广泛采用断言，以增强程序的调试功能。
10.   用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况。
11.   不能用断言来检查最终产品肯定会出现且必须处理的错误情况。
12.   对较复杂的断言加上明确的注释。
13.   用断言确认函数的参数。
14.   用断言保证没有定义的特性或功能不被使用。
15.   用断言对程序开发环境的假设进行检查。
16.   正式软件产品中应把断言及其他调测代码去掉（即把有关的调测开关关掉）。
17.   在软件系统中设置与取消有关测试手段，不能对软件实现的功能等产生影响。
18.   用调测开关来切换软件的DEBUG版本和正式版，而不要同时存在正式版本和DEBUG版本的不同源文件，以减少维护的难度。软件的DEBUG版本和正式发行版本应该统一维护，不允许分家，并且要时刻注意保证两个在实现功能上的一致性。
19.   在编写代码之前，应预先设计好程序调试与测试的方法和手段，并设计好各种调测开
关及相应测试代码如打印函数等。
20.   调测开关应分为不同级别和类型。
21.   编写防错程序，然后在处理错误之后可用断言宣布发生错误。
22.   在程序设计中，对异常情况的处理方法有两种：（1）若该异常情况会在正式版本中出现，则应保留对该情况的处理分支；（2）若该异常情况只会在调试阶段出现，则应对该异常做断言检查。


七 程序效率

1.   编程时要经常注意代码的效率。在保证软件系统的正确性、稳定性、可读性及可测性的前提下，提高代码效率。
2.   局部效率应为全局效率服务，不能因为提高局部效率而对全局效率造成影响。
3.   通过对系统数据结构的划分与组织的改进，以及对程序算法的优化来提高空间效率。
4.   仔细分析有关算法，并进行优化。
5.   仔细考查、分析系统及模块处理输入（事务、消息等）的方式，并加以改进。
6.   对模块中函数的划分及组织方式进行分析、优化，改进模块中函数的组织结构，提高程序效率。
7.   编程时，要随时留心代码效率；优化代码时要考虑周全。不必花过多时间用以提高不经常调用的函数代码的效率。要仔细地构造或直接用汇编编写调用频繁和性能要求极高的函数。
8.   在保证程序质量的前提下，通过压缩代码量、去掉不必要代码以及减少不必要的局部和全局变量，来提高空间效率。
9.   尽量减少循环嵌套层次。在多重循环中，应将最忙的循环放在最内层。
10.   避免循环体内含判断语句，应将循环语句置于判断语句的代码块之内。争取循环体内工作量最小化。
11.   尽量用乘法或其他方法代替除法，特别是浮点运算中的除法。
在多重条件判断时，尽量把简短的处理过程放在前面（或判断时将容易成立的放前面，与判断时将不容易成立的放前面），复杂的处理过程放在后面，提高代码的执行效率

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。