it网络设备公司软件编程规范和范例(华为)(编辑修改稿)内容摘要:
User允许。 189。 31:除非必要,不要用数字或较奇怪的字符来定义标识符 示例:如下命名,使 人产生疑惑。 define _EXAMPLE_0_TEST_ define _EXAMPLE_1_TEST_ void set_sls00( BYTE sls )。 应改为有意义的单词命名 define _EXAMPLE_UNIT_TEST_ define _EXAMPLE_ASSERT_TEST_ void set_udt_msg_sls( BYTE sls )。 189。 32:在同一软件产品内,应规划好接口部分标识符(变量、结构、函数及常量)的命名,防止编译、链接时产生冲突 说明:对接口部分的标识符 应该有更严格限制,防止冲突。 如可规定接口部分的变量与常量之前加上 “模块 ”标识等。 189。 33:用正确的反义词组命名具有互斥意义的变量或相反动作的函数等 说明:下面是一些在软件中常用的反义词组。 add / remove begin / end create / destroy insert / delete first / last g et / release increment / decrement put / get add / delete lock / unlock open / close min / max old / new start / stop next / previous source / target show / hide send / receive source / destination cut / paste up / down 示例 : int min_sum。 int max_sum。 int add_user( BYTE *user_name )。 int delete_user( BYTE *user_name )。 189。 34: 除了编译开关 /头文件等特殊应用 , 应避免使用 _EXAMPLE_TEST_之类以下划线开始和结尾的定义 〔四〕 =====[ 可读性 ]====== 185。 4 1:注意运算符的优先级,并用括号明确表达式的操作顺序,避免使用默认优先级 说明:防止阅读程序时产生误解,防止因默认的优先级与设计思想不符而导致程序出错。 示例:下列语句中的表达式 word = (high 8) | low (1) if ((a | b) amp。 amp。 (a amp。 c)) (2) if ((a | b) (c amp。 d)) (3) 如果书写为 : high 8 | low a | b amp。 amp。 a amp。 c a | b c amp。 d 由于 high 8 | low = ( high 8) | low, a | b amp。 amp。 a amp。 c = (a | b) amp。 amp。 (a amp。 c), (1)(2)不会出错,但语句不易理解; a | b c amp。 d = a | ( b c) amp。 d, (3)造成了判断条件出错。 185。 4 2:避免使用不易理解的数字,用有意义的标识来替代。 涉及物理状态或者含有物理意义的常量,不应直接使用数字,必须用有意义的枚举或宏来代替 示例:如下的程序可读性差。 if (Trunk[index].trunk_state == 0) { Trunk[index].trunk_state = 1。 ... // program code } 应改为如下形式。 define TRUNK_IDLE 0 define TRUNK_BUSY 1 if (Trunk[index].trunk_state == TRUNK_IDLE) { Trunk[index].trunk_state = TRUNK_BUSY。 ... // program code } 189。 41:源程序中关系较为紧密的代码应尽可能相邻 说明:便于程序阅读和查找。 示例:以下代码布局不太合理。 = 10。 char_poi = str。 = 5。 若按如下形式书写,可能更清晰一些。 = 10。 = 5。 // 矩形的长与宽关系较密切,放在一起。 char_poi = str。 189。 42:不要使用难懂的技巧性很高的语句,除非很有必要时 说明:高技巧语句不等于高效率的程序,实际上程序的效率关键在于算法。 示例:如下表达式,考虑不周就可能出问题,也较难理解。 * stat_poi ++ += 1。 * ++ stat_poi += 1。 应分别改为如下 : *stat_poi += 1。 stat_poi++。 // 此二语句功能相当于 “ * stat_poi ++ += 1。 ” ++ stat_poi。 *stat_poi += 1。 // 此二语句功能相当于 “ * ++ stat_poi += 1。 ” 〔五〕 =====[ 变量、结构 ]===== 185。 5 1:去掉没必要的公共变量 说明:公共变量是增大模块间耦合的原因之一,故应减少没必要的公共变量以降低模块间的耦合度。 185。 5 2:仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系 说明:在对变量声明的同时,应对其含义、作用及取值范围进行注释说明,同时若有必要还应说明与其它变量的关系。 185。 53:明确公共变量与操作此公共变量的函数或过程的关系,如访问、修改及创建等 说明:明确过程操作变量的关系后,将有利于程序的进一步优化、单元测试、系统联调以及代码维护等。 这种关系的说明可在注释或文档中描述。 示例:在源文件中,可按如下注释形式说明。 RELATION System_Init Input_Rec Print_Rec Stat_Score Student Create Modify Access Access Score Create Modify Access Access, Modify 注: RELATION为操作关系; System_Init、 Input_Rec、 Print_Rec、 Stat_Score为四个不同的函数;Student、 Score为两个全局变量; Create表示创建, Modify表示修改, Access 表示访问。 其中,函数 Input_Rec、 Stat_Score都可修改变量 Score,故此变量将引起函数间较大的耦合,并可能增加代码测试、维护的难度。 185。 5 4:当 向公共变量传递数据时,要十分小心,防止赋与不合理的值或越界等现象发生 说明:对公共变量赋值时,若有必要应进行合法性检查,以提高代码的可靠性、稳定性。 185。 5 5:防止局部变量与公共变量同名 说明:若使用了较好的命名规则,那么此问题可自动消除。 185。 5 6:严禁使用未经初始化的变量作为右值 说明:特别是在 C/C++中引用未经赋值的指针,经常会引起系统崩溃。 189。 51:构造仅有一个模块或函数可以修改、创建,而其余有关模块或函数只访问的公共变量,防止多个不同模块或函数都可以修改、创建同一公共变量的现象 说明:降低公共 变量耦合度。 189。 52:使用严格形式定义的、可移植的数据类型,尽量不要使用与具体硬件或软件环境关系密切的变量 说明:使用标准的数据类型,有利于程序的移植。 示例:如下例子(在 DOS下 环境中),在移植时可能产生问题。 void main() { register int index。 // 寄存器变量 _AX = 0x4000。 // _AX是 提供的寄存器 “伪变量 ” ... // program code } 189。 53:结构的功能要单一,是针对一种事务的抽象 说明: 设计结构时应力争使结构代表一种现实事务的抽象,而不是同时代表多种。 结构中的各元素应代表同一事务的不同侧面,而不应把描述没有关系或关系很弱的不同事务的元素放到同一结构中。 示例:如下结构不太清晰、合理。 typedef struct STUDENT_STRU { unsigned char name[8]。 /* student39。 s name */ unsigned char age。 /* student39。 s age */ unsigned char sex。 /* student39。 s sex, as follows */ /* 0 FEMALE。 1 MALE */ unsigned char teacher_name[8]。 /* the student teacher39。 s name */ unisgned char teacher_sex。 /* his teacher sex */ } STUDENT。 若改为如下,可能更合理些。 typedef struct TEACHER_STRU { unsigned char name[8]。 /* teacher name */ unisgned char sex。 /* teacher sex, as follows */ /* 0 FEMALE。 1 MALE */ } TEACHER。 typedef struct STUDENT_STRU { unsigned char name[8]。 /* student39。 s name */ unsigned char age。 /* student39。 s age */ unsigned char sex。 /* student39。 s sex, as follows */ /* 0 FEMALE。 1 MALE */ unsigned int teacher_ind。 /* his teacher index */ } STUDENT。 189。 54:不要设计面面俱到、非常灵活的数据结构 说明:面面俱到、灵活的数据结构反而容易引起误解和操作困难。 189。 55:不同结构间的关系不要过于复杂 说明:若两个结构间关系较复杂、密切,那么应合为一个结构。 示例:如下两个结构的构造不合理。 typedef struct PERSON_ONE_STRU { unsigned char name[8]。 unsigned char addr[40]。 unsigned char sex。 unsigned char city[15]。 } PERSON_ONE。 typedef struct PERSON_TWO_STRU { unsigned char name[8]。 unsigned char age。 unsigned char tel。 } PERSON_TWO。 由于两个结构都是描述同一事物的,那么不如合成一个结构。 typedef struct PERSON_STRU { unsigned char name[8]。 unsigned char age。 unsigned char sex。 unsigned char addr[40]。 unsigned char city[15]。 unsigned char tel。 } PERSON。 189。 56:结构中元素的个数应适中。 若结构中元素个数过多可考虑依据某种原则把元素组成不同的子结构,以减少原结构中元素的个数 说明:增加结构的可理解性、可操作性和可维护性。 示例:假如认为如上的 _PERSON结构元素过多,那么可如下对之划分。 typedef struct PERSON_BASE_INFO_STRU { unsigned char name[8]。 unsigned char age。 unsigned char sex。 } PERSON_BASE_INFO。 typedef struct PERSON_ADDRESS_STRU { unsigned char addr[40]。 unsigned char city[15]。 unsigned char tel。 } PERSON_ADDRESS。 typedef struct PERSON_STRU { PERSON。it网络设备公司软件编程规范和范例(华为)(编辑修改稿)
相关推荐
括: 事件 请求的处理(包括直接解决、 拒绝、 任务分派和事件记录); 事件跟踪; 所有 服务事件统计查询; 知识库添加和查询; 公告发布管理; 服务目录管理; 规章制度添加修改; 自身服务报告查询和记录; 供应商管理; 远程诊断; 运维工具箱上传、下载。 5. 服务台经理 主要负责 各类服务事件的统计、查询,以及事件 的处理及分派工作。
F、其他 ________ 公司 在 晋升 评定及工资等级划分方面是否公平公正公开。 是 否 (请 填写您自己的观点): : A、每次反馈都 有 新的启发,让我知道工作中的缺陷,共同探讨改进办法 B、有时还可以,有时很难说服我 C、基本不反馈,走形式 D、领导怎么定就怎么定,无所谓 E、我的上司 很糊涂,自己不以身作则,对我要求却很苛刻。 公司
一块。 洗衣袋 每房二只。 面巾纸 每房一盒。 剃须刀 每房可备二把。 可配备须膏。 指甲锉 每房可备一把。 棉花球、棉签 每房宜备 一套。 浴盐 (泡沫剂、苏打盐 ) 五星级可配备。 文具用品 文具夹 (架 ) 每房一只。 信封、明信片 每房普通信封、航空信封和国际信封各不少于二只,明信片二张。 信纸、便笺、传真纸 每房信纸、便笺各不少于四张,传真纸不少于二张。 圆珠笔 每房不少于一支。 铅笔
第 4 页 共 69 页 系统接口 ......................................................................................................................... 59 编程时,要防止差 1 错误 ..........................................
格标准 版本号 第 15 页,共 24 页 02产品设计规格确定 01客户交流 /调研 /报告 客户交流、查阅文献,市场需求、现状调查,写调研报告 02技术讨论 /学习 /接受培训 系统设计研讨、受训、协议研究,开发测试文档模板写作培训等 03结构需求分解和分配 完成需求的分解,完成《分解和分配》过程文档 04设计规格书 完成《设计规格书》文档 05技术评审 2 设计规格评审 06设计规格书修改
—— 摘自《管理要点》 刊号 :第 80 期 标题 :各系统对公司级 KPI 体系的讨论意见 内容 : 2 月 3 日到 2 月 5 日,公司各系统对“华为公司公司级关键绩效指标 (KPI)体系 (草案 )”进行了认真讨论。 经过讨论,对本次制订公司级 KPI 的思路、原则有了更深入和更具体的理解,尤其是增强了对强化公司整体核心竞争力、形成连带 责任和坚持最终成果导向的价值评 价体系的全面理解。