C C++编程规范总则

合集下载

Linux C语言的编程规范

Linux C语言的编程规范

Linux C语言的编程规范(Linux)有独特的(编程)风格,在内核源代码目录Documentation/CodingStyle,详细描述代码风格。

建议大家可以去看一下,老外写技术文档还是很有意思的,上来就狂喷,“你不这样写就会完蛋,异教徒才不这样写……”,没有国内那么刻板,多阅读英语文档对技术增长很有帮助。

1. 命名规范在一般编程中,习惯以如下方式命名宏、变量和函数:#define (PI)3.1415926 /*用大写字母代表宏*/int minValue, maxValue; /*变量:第一个单词全小写,其后单词的第一个字母大写*/void SendData (void); /* 函数:所有单词第一个字母都大写*/ 这种通过单词之间通过首字母大写来区分的方式非常流行。

通过第1个单词的首字母是否大写可以区分名称属于变量还是属于函数,而看到整串的大写字母可以断定为宏。

许多领域的程序开发都遵照此习惯。

但是Linux不以这种习惯命名,对于上面的一段程序,在Linux中它会被命名为:#define PI 3.1415926int min_value, max_value;void send_data (void); 在上述命名方式中,宏还是一样用大写,但变量和函数名,不按照Windows所采用的用首字母大写来区分单词,而是采用下划线。

而且Linux下命名,全局变量命名最好用长的准确的描述,局部变量最好简短,甚至直接用tmp,i之类的。

其实两种命名方式都行,写Liunx下的程序时,与Linux社区代码风格一致更好,但你用第一种我觉得也无伤大雅。

2.缩进缩进统一使用"TAB",而不是空格括号。

另外提一句:在Linux下,"TAB"代表8个字符,而不是4个,Linux代码风格认为8个字符更能体现层次结构。

文档里喷"TAB"为4字符的是异教徒,对于8字符在多层次时,代码太偏右的问题,文档又喷层次超过三层,你的代码就会完蛋,哈哈哈。

mcu-c编程规范

mcu-c编程规范

MCU-C程序基本编程规范(转)[ 2010-4-14 13:35:00 | By: gdqinci ]MCU-C程序基本编程规范(转)为了提高源程序的质量和可维护性,从而最终提高软件产品生产力,特编写此规范。

本标准规定了程序设计人员进行程序设计时必须遵循的规范。

本规范主要针对单片机编程语言和08编译器而言,包括排版、注释、命名、变量使用、代码可测性、程序效率、质量保证等内容。

1.基本规则格式清晰、注释简明扼要、命名规范易懂、函数模块化、程序易读易维护、功能准确实现、代码空间效率和时间效率高、适度的可扩展性、单片机编程规范-标识符命名2.标识符命名2.1命名基本原则(1)命名清晰明了,有明确含义,使用完整单词或约定俗成的缩写。

通常,较短的单词可通过去掉元音字母形成缩写;较长的单词可取单词的头几个字母形成缩写。

即"见名知意"。

(2)命名风格要自始至终保持一致。

(3)命名中若使用特殊约定或缩写,要有注释说明。

(4)同一软件产品内模块之间接口部分的标识符名称之前加上模块标识。

2.2宏和常量命名宏和常量用全部大写字母来命名,词与词之间用下划线分隔。

对程序中用到的数字均应用有意义的枚举或宏来代替。

2.3变量命名变量名用小写字母命名,每个词的第一个字母大写。

类型前缀(u8\s8 etc.)全局变量另加前缀g_。

局部变量应简明扼要。

局部循环体控制变量优先使用i、j、k等;局部长度变量优先使用len、num等;临时中间变量优先使用temp、tmp等。

2.4函数命名函数名用小写字母命名,每个词的第一个字母大写,并将模块标识加在最前面。

2.5文件命名一个文件包含一类功能或一个模块的所有函数,文件名称应清楚表明其功能或性质。

每个.c文件应该有一个同名的.h文件作为头文件。

3.注释3.1注释基本原则有助于对程序的阅读理解,说明程序在"做什么",解释代码的目的、功能和采用的方法。

一般情况源程序有效注释量在30%左右。

cert c 编码标准

cert c 编码标准

CERT C 编码标准============本文档旨在介绍CERT(C 语言编码标准)中的一些主要方面,包括文件排版、注释规范和变量声明和初始化等。

这些标准是用于编写安全、可维护和一致的C 语言代码的重要指南。

1. 文件排版-------* 文件名应采用小写字母和下划线的组合,以描述性的方式命名。

* 每个源代码文件应以`.c` 或`.h` 作为文件扩展名。

* 代码应按照模块化原则组织,将相关的函数和数据结构分组到头文件和源文件中。

* 在源文件中,函数和数据结构应按照逻辑关系进行排序,以便于阅读和维护。

* 每个源文件应以包含一个定义了函数和数据结构的头文件开始。

* 在每个源文件中,函数和数据结构应以清晰、易于阅读的格式进行排列。

* 在代码中,缩进应一致,以增强代码的可读性。

建议使用四个空格作为缩进单位。

* 行长度不应超过80个字符,以提高代码的可读性。

* 在函数之间应使用空行分隔,以增强代码的可读性。

2. 注释规范-------* 在源文件的顶部,应包含一个简短的注释,描述文件的作用和内容。

* 在每个函数之前,应添加一个注释块,描述函数的作用、输入参数和返回值。

* 在复杂的代码段之前,应添加注释说明代码的目的和实现方法。

* 对于全局变量和重要数据类型,应添加注释说明其作用和使用方法。

* 对于不常用的函数或数据结构,应添加注释说明其使用方法和实现细节。

* 对于代码中的重要决策点或特殊处理,应添加注释说明原因和实现细节。

* 对于可能产生副作用的函数调用,应添加注释说明其可能的影响和注意事项。

* 对于需要调试的代码段,应添加注释说明调试方法和可能的错误原因。

* 对于使用到的第三方库或工具,应添加注释说明其版本号、作用和使用方法。

* 对于可能存在的性能问题或潜在的优化点,应添加注释说明原因和解决方案。

3. 变量声明和初始化--------------* 在函数内部,变量应尽早声明和使用。

* 在函数内部,不应声明多个变量在同一行。

C++编程规范及要求

C++编程规范及要求

C++编码规范及要求王卓有关C、C++的编码风格和程序质量可以参照《高质量C/C++编程》1 概述错误!未定义书签。

2 字体及颜色错误!未定义书签。

3 文件结构错误!未定义书签。

文件头注释错误!未定义书签。

头文件错误!未定义书签。

实现文件错误!未定义书签。

文件的组织结构错误!未定义书签。

4 命名规则错误!未定义书签。

类/结构错误!未定义书签。

函数错误!未定义书签。

变量错误!未定义书签。

常量错误!未定义书签。

枚举、联合、typedef 错误!未定义书签。

宏、枚举值错误!未定义书签。

名空间错误!未定义书签。

5 代码风格与版式错误!未定义书签。

类/结构错误!未定义书签。

函数错误!未定义书签。

变量、常量错误!未定义书签。

枚举、联合、typedef 错误!未定义书签。

宏错误!未定义书签。

名空间错误!未定义书签。

异常错误!未定义书签。

概述高品质、易维护的软件开发离不开清晰严格的编码规范。

本文档详细描述C++软件开发过程中的编码规范。

本规范也适用于所有在文档中出现的源码。

字体及颜色强烈推荐采用Visual Assist X作为Visual Studio的辅助工具。

在编辑源码时,应该根据编辑器支持的自定义选项最大限度地满足下表定义的高亮规范。

Windows平台中,应该优先使用字体:Fixedsys,这也是操作系统UI(所有的菜单、按钮、标题栏、对话框等等)默认使用的字体。

该字体的好处很多:1、兼容性好:所有Windows平台都支持该字体2、显示清晰:该字体为点阵字体,相对于矢量字体来说在显示器中呈现的影像更为清晰。

矢量字体虽然可以自由缩放,但这个功能对于纯文本格式的程序源码来说没有任何实际作用。

而且当显示字号较小(12pt以下)时,矢量字体还有一些明显的缺陷:文字的边缘会有严重的凹凸感。

一些笔画的比例也会失调。

开启了柔化字体边缘后,还会使文字显得模糊不清。

3、支持多语言:Fixedsys是UNICODE字体,支持世界上几乎所有的文字符号。

标准C语言规范

标准C语言规范
* 编程人员 : 宋毅红
* 编程时间 : 94.9.29
* 修改时间 :
*/
#include <curses.h>
#include <signal.h>
#include <fcntl.h>
#include "Tr_mac.h"
#include "Tr_str.h"
return(Err);
}
}
/******* added by yang yijun 95.7.25 *****/
else
{
_disp_nm(bgdc.cur); /* yyj 94.11.17.*/
return(Err);
}
}
return(Ok);
}
void_disp_nm( _sName)
char *_sName;
p------pointer
字符串数组也使用p标志
静态变量名前用s标志
数组变量名前用stru标志
全局变量使用前缀g_标志
如:dBalance,fInterest,pName,sCustomer,struPersonWang,g_iOperNo
3.书写规范
⑴对齐原则
同一层次的语句必须左对齐。“{”和“}”必须独占一行。
⑵缩进原则
不同层次的语句必须遵从缩进原则,一般缩进四个字符为宜,TAB值设为4。
Case后的语句(简短注释语句除外)应另起一行,且须与“:”相接。
⑶分行书写原则
当行超过屏幕上的行时,应分行书写。
⑷注释符要求
单行注释符使用“//”,多行注释符使用“/*……*/”,注释符必须遵从前面3条原则,

C++编程规范

C++编程规范

C++编程规范审核记录目录1文档介绍 (5)1.1文档目的 (5)1.2文档范围 (5)1.3读者对象 (5)2命名规范 (5)2.1源代码文件名 (7)2.2执行代码名 (7)2.3程序维护文件名 (8)2.4函数名 (8)2.5变量名 (8)2.6结构名 (8)2.7循环变量 (9)2.8异常处理 (9)3编码规则 (9)3.1类 (9)3.2函数 (10)3.2.1修订记录 (10)3.2.2注释 (11)3.2.3头文件 (12)3.2.4命名 (12)3.2.5函数规范 (12)3.2.6函数参数 (16)3.2.7参数顺序 (17)3.2.8用指针作为出参 (17)3.2.9真/假类型 (17)3.2.10函数功能单一 (18)3.2.11防错型编程 (18)3.3变量 (18)3.3.1命名 (18)3.3.2使用 (22)3.3.3局部变量 (25)3.3.4全局变量 (25)3.4语句 (25)3.4.1if (25)3.4.2case (26)3.4.3while (26)3.4.4for (26)3.4.5do...while . (27)3.4.6goto (27)3.5其它规则 (27)4编码风格 (29)4.1缩格 (29)4.2{}匹配 (29)4.3()匹配 (29)4.4空格 (29)4.5注释 (30)4.6段落 (30)4.7宏定义 (30)4.8数据类型定义 (31)4.9注释 (31)4.10程序 (31)4.11其它 (32)5开发系统维护 (34)5.1专人负责 (34)5.2版本管理 (34)C++编码规范1 文档介绍本文用于说明系统开发过程中,所需遵循的一些原则、规定。

使系统开发成员在进行工作时能够统一开发方式,从而使系统的各个环节都能够得到有效统一地表示、定义,便于相关人员进行统一的管理和维护。

1.1 文档目的统一系统开发过程中的数据命名方式、定义方式和编码方式。

C++编程规范(C++ Programming Conventions)

C++编程规范(C++ Programming Conventions)

C++ Programming ConventionsC++编程规范Prepared by拟制谭琳琳Date日期2007-7-10Reviewed by 评审人SEPG teamDate日期2007-7-20Approved by批准田松涛Date日期2007-7-23Revision Record 修订记录Table of Contents 目录1概述 (4)1.1目的 (4)1.2主要内容 (4)1.3术语说明 (4)2C++编程规范 (4)2.1排版 (4)2.1.1缩进风格 (4)2.1.2代码风格 (7)2.1.3分行 (7)2.1.4空行 (7)2.1.5空格 (7)2.2注释和命名基本规范 (8)2.2.1注释 (8)2.2.2命名 (10)2.3类(class) 规范 (10)2.3.1类命名 (11)2.3.2类注释 (11)2.3.3类的设计 (11)2.4属性(Attribute) 规范 (12)2.4.1属性命名 (12)2.4.2属性注释 (14)2.4.3属性的可见性 (14)2.4.4属性使用 (14)2.5方法(Method) 规范 (14)2.5.1方法命名 (14)2.5.2方法注释 (15)2.5.3代码注释 (16)2.5.4方法实现 (16)2.6可测性 (17)2.7可读性 (17)2.8代码效率 (18)2.9代码优化 (18)1 概述1.1 目的本文档目的在于规范C++开发人员的编程风格,提高代码可读性和可维护性。

1.2 主要内容本文档主要包括C++编程规范:从排版,类、属性、方法的命名、注释、可见性、设计,以及可读性、可测试性等方面对C++编程作了规范。

1.3 术语说明规则:编程时强制必须遵守的原则。

建议:编程时必须加以考虑的原则。

格式:对此规范格式的说明。

说明:对此规范或建议进行必要的解释。

示例:对此规范或建议从正、反两个方面给例子。

约定:项目组内部约定,编程时必须执行。

c命名规范

c命名规范

c命名规范C命名规范是指在编程中为变量、函数、类、常量等标识符取名的一套规则。

遵循良好的命名规范可以增加代码的可读性和可维护性,方便他人理解和使用代码。

一、命名原则1. 可读性原则:命名要具有可读性,方便其他人理解代码的含义。

避免使用缩写、不清晰的变量名或拼音命名,尽量使用有意义的单词或词组。

2. 一致性原则:命名应保持统一,遵循团队或项目的约定。

相同类型的标识符命名应统一,不同类型的标识符命名应区分开。

3. 易于搜索原则:命名要便于搜索和定位。

避免使用过长的命名,但也要避免使用过短的命名,使得标识符在项目中易于搜索和找到。

二、标识符的命名规范1. 变量和函数命名:使用小写字母和下划线,多个单词之间用下划线分隔。

例如:user_name, calculate_price。

2. 类的命名:使用驼峰命名法,即首字母大写,不使用下划线。

例如:UserInfo, CarFactory。

3. 常量的命名:使用大写字母和下划线,多个单词之间用下划线分隔。

例如:MAX_NUMBER, PI_VALUE。

4. 包名的命名:使用小写字母,多个单词之间使用点"."分隔。

例如:com.example.project。

5. 枚举类型的命名:使用大写字母和下划线,多个单词之间用下划线分隔。

例如:Color.RED, Season.SUMMER。

三、命名的约定1. 命名要有意义,尽量反映标识符的用途和含义,避免使用无意义的命名。

2. 避免使用保留字和关键字作为标识符,例如:int, float, if, else等。

3. 避免使用单个字母或数字作为标识符,除非是临时变量或索引变量。

4. 当命名较长时,可以使用缩写,但要确保缩写被广泛接受并易于理解。

5. 避免使用拼音命名,特别是在英文环境下,可能导致理解困难。

6. 命名要避免歧义和混淆,尽量不要使用相似的标识符,容易造成误解。

四、常见命名错误1. 不符合命名规范:命名不清晰、不规范,缺乏可读性和可维护性。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

1 排版 (5)¹1-1:程序块要采用缩进风格编写,缩进的空格数为4个。

(5)¹1-2:相对独立的程序块之间、变量说明之后必须加空行。

(5)¹1-3:较长的语句(>80字符)要分成多行书写,长表达式要在低优先级操作符处划分新行,操作符放在新行之首,划分出的新行要进行适当的缩进,使排版整齐,语句可读。

(5)¹1-4:循环、判断等语句中若有较长的表达式或语句,则要进行适应的划分,长表达式要在低优先级操作符处划分新行,操作符放在新行之首。

(6)¹1-5:若函数或过程中的参数较长,则要进行适当的划分。

(6)¹1-6:不允许把多个短语句写在一行中,即一行只写一条语句。

(6)¹1-7:if、for、do、while、case、switch、default等语句自占一行,且if、for、do、while等语句的执行语句部分无论多少都要加括号{}。

(7)¹1-8:对齐只使用空格键,不使用TAB键。

(7)¹1-9:函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格,case语句下的情况处理语句也要遵从语句缩进要求。

(7)¹1-10:程序块的分界符(如C/C++语言的大括号‘{’和‘}’)应各独占一行并且位于同一列,同时与引用它们的语句左对齐。

在函数体的开始、类的定义、结构的定义、枚举的定义以及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。

(7)¹1-11:在两个以上的关键字、变量、常量进行对等操作时,它们之间的操作符之前、之后或者前后要加空格;进行非对等操作时,如果是关系密切的立即操作符(如->),后不应加空格。

(8)2 注释 (10)¹2-1:一般情况下,源程序有效注释量必须在20%以上。

(10)¹2-2:说明性文件(如头文件.h文件、.inc文件、.def文件、编译说明文件.cfg等)头部应进行注释,注释必须列出:版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等,头文件的注释中还应有函数功能简要说明。

(10)¹2-3:源文件头部应进行注释,列出:版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。

(10)¹2-4:函数头部应进行注释,列出:函数的目的/功能、输入参数、输出参数、返回值、调用关系(函数、表)等。

(11)¹2-5:边写代码边注释,修改代码同时修改相应的注释,以保证注释与代码的一致性。

不再有用的注释要删除。

(12)¹2-6:注释的内容要清楚、明了,含义准确,防止注释二义性。

(12)¹2-8:注释应与其描述的代码相近,对代码的注释应放在其上方或右方(对单条语句的注释)相邻位置,不可放在下面,如放于上方则需与其上面的代码用空行隔开。

(12)¹2-9:对于所有有物理含义的变量、常量,如果其命名不是充分自注释的,在声明时都必须加以注释,说明其物理含义。

变量、常量、宏的注释应放在其上方相邻位置或右方。

(12)¹2-10:数据结构声明(包括数组、结构、类、枚举等),如果其命名不是充分自注释的,必须加以注释。

对数据结构的注释应放在其上方相邻位置,不可放在下面;对结构中的每个域的注释放在此域的右方。

(13)¹2-11:全局变量要有较详细的注释,包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明。

(13)¹2-12:注释与所描述内容进行同样的缩排。

(13)¹2-13:将注释与其上面的代码用空行隔开。

(14)¹2-14:对变量的定义和分支语句(条件分支、循环语句等)必须编写注释。

(14)¹2-15:对于switch语句下的case语句,如果因为特殊情况需要处理完一个case后进入下一个case处理,必须在该case语句处理完、下一个case语句前加上明确的注释。

(14)3 标识符命名 (18)¹3-1:标识符的命名要清晰、明了,有明确含义,同时使用完整的单词或大家基本可以理解的缩写,避免使人产生误解。

(18)¹3-2:命名中若使用特殊约定或缩写,则要有注释说明。

(18)¹3-3:自己特有的命名风格,要自始至终保持一致,不可来回变化。

(18)¹3-4:对于变量命名,禁止取单个字符(如i、j、k...),建议除了要有具体含义外,还能表明其变量类型、数据类型等,但i、j、k作局部循环变量是允许的。

(18)¹3-5:命名规范必须与所使用的系统风格保持一致,并在同一项目中统一,比如采用UNIX的全小写加下划线的风格或大小写混排的方式,不要使用大小写与下划线混排的方式,用作特殊标识如标识成员变量或全局变量的m_和g_,其后加上大小写混排的方式是允许的。

(19)4 可读性 (21)¹4-1:注意运算符的优先级,并用括号明确表达式的操作顺序,避免使用默认优先级。

21¹4-2:避免使用不易理解的数字,用有意义的标识来替代。

涉及物理状态或者含有物理意义的常量,不应直接使用数字,必须用有意义的枚举或宏来代替。

(21)5 变量、结构 (23)¹5-1:去掉没必要的公共变量。

(23)¹5-2:仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系。

(23)¹5-3:明确公共变量与操作此公共变量的函数或过程的关系,如访问、修改及创建等。

23¹5-4:当向公共变量传递数据时,要十分小心,防止赋与不合理的值或越界等现象发生。

23¹5-5:防止局部变量与公共变量同名。

(23)¹5-6:严禁使用未经初始化的变量作为右值。

(23)6 函数、过程 (30)¹6-1:对所调用函数的错误返回码要仔细、全面地处理。

(30)¹6-2:明确函数功能,精确(而不是近似)地实现函数设计。

(30)¹6-3:编写可重入函数时,应注意局部变量的使用(如编写C/C++语言的可重入函数时,应使用auto即缺省态局部变量或寄存器变量)。

(30)¹6-4:编写可重入函数时,若使用全局变量,则应通过关中断、信号量(即P、V操作)等手段对其加以保护。

(30)¹6-5:在同一项目组应明确规定对接口函数参数的合法性检查应由函数的调用者负责还是由接口函数本身负责,缺省是由函数调用者负责。

(31)7 可测性 (39)¹7-1:在同一项目组或产品组内,要有一套统一的为集成测试与系统联调准备的调测开关及相应打印函数,并且要有详细的说明。

(39)¹7-2:在同一项目组或产品组内,调测打印出的信息串的格式要有统一的形式。

信息串中至少要有所在模块名(或源文件名)及行号。

(39)¹7-3:编程的同时要为单元测试选择恰当的测试点,并仔细构造测试代码、测试用例,同时给出明确的注释说明。

测试代码部分应作为(模块中的)一个子模块,以方便测试代码在模块中的安装与拆卸(通过调测开关)。

(39)¹7-4:在进行集成测试/系统联调之前,要构造好测试环境、测试项目及测试用例,同时仔细分析并优化测试用例,以提高测试效率。

(39)¹7-5:使用断言来发现软件问题,提高代码可测性。

(39)¹7-6:用断言来检查程序正常运行时不应发生但在调测时有可能发生的非法情况。

(40)¹7-7:不能用断言来检查最终产品肯定会出现且必须处理的错误情况。

(40)¹7-8:对较复杂的断言加上明确的注释。

(40)¹7-9:用断言确认函数的参数。

(40)¹7-10:用断言保证没有定义的特性或功能不被使用。

(40)¹7-11:用断言对程序开发环境(OS/Compiler/Hardware)的假设进行检查。

(41)¹7-12:正式软件产品中应把断言及其它调测代码去掉(即把有关的调测开关关掉)。

(41)¹7-13:在软件系统中设置与取消有关测试手段,不能对软件实现的功能等产生影响。

(41)¹7-14:用调测开关来切换软件的DEBUG版和正式版,而不要同时存在正式版本和DEBUG版本的不同源文件,以减少维护的难度。

(41)¹7-15:软件的DEBUG版本和发行版本应该统一维护,不允许分家,并且要时刻注意保证两个版本在实现功能上的一致性。

(42)8 程序效率 (44)¹8-1:编程时要经常注意代码的效率。

(44)¹8-2:在保证软件系统的正确性、稳定性、可读性及可测性的前提下,提高代码效率。

44¹8-3:局部效率应为全局效率服务,不能因为提高局部效率而对全局效率造成影响。

(44)¹8-4:通过对系统数据结构的划分与组织的改进,以及对程序算法的优化来提高空间效率。

(44)¹8-5:循环体内工作量最小化。

(45)9 质量保证 (49)¹9-1:在软件设计过程中构筑软件质量。

(49)¹9-2:代码质量保证优先原则 (49)¹9-3:只引用属于自己的存贮空间。

(49)¹9-4:防止引用已经释放的内存空间。

(49)¹9-5:过程/函数中分配的内存,在过程/函数退出之前要释放。

(49)¹9-6:过程/函数中申请的(为打开文件而使用的)文件句柄,在过程/函数退出之前要关闭。

(49)¹9-7:防止内存操作越界。

(50)¹9-8:认真处理程序所能遇到的各种出错情况。

(51)¹9-9:系统运行之初,要初始化有关变量及运行环境,防止未经初始化的变量被引用。

51¹9-10:系统运行之初,要对加载到系统中的数据进行一致性检查。

(51)¹9-11:严禁随意更改其它模块或系统的有关设置和配置。

(51)¹9-12:不能随意改变与其它模块的接口。

(51)¹9-13:充分了解系统的接口之后,再使用系统提供的功能。

(51)¹9-14:编程时,要防止差1错误。

(53)¹9-15:要时刻注意易混淆的操作符。

当编完程序后,应从头至尾检查一遍这些操作符,以防止拼写错误。

(53)¹9-16:有可能的话,if语句尽量加上else分支,对没有else分支的语句要小心对待;switch语句必须有default分支。

相关文档
最新文档