17、C/C++编程规范精述

简介: C/C++编程规范精述 (匈牙利命名法) 1、排版上不同小结构间要空行分开,子逻辑项相对父逻辑项要缩进;{及if,while等判断语句应独占行并对齐,且后加空格以显突出。 2、注释位于相应代码上面或右旁边。

C/C++编程规范精述

(匈牙利命名法)

1、排版上不同小结构间要空行分开,子逻辑项相对父逻辑项要缩进;{及ifwhile等判断语句应独占行并对齐,且后加空格以显突出。

2、注释位于相应代码上面或右旁边。且与其它代码空行或空格隔开。

3、变量命名风格:采用UNIX 的全小写加下划线的风格或大小写混排的方式,不要使用大小写与下划线混排的方式,但用作特殊标识如标识成员变量或全局变量的m_g_,其后加上大小写混排的方式是允许的。

定义标识符(变量名/函数名)应体现code is document:类型的第一个字母小写组合 + 有意义的单词。全局变量和函数名前应加模块名。

DWORD dwSum = 0;

定义变量应当初始化,尤其是在使用前。

全局变量/静态变量要注意可重入性(经过处理才可以)。结构定义应当尽是以4字节(32CPU一个指令就可以存取)对齐的。typedef 结构体时,不应当只定义指针。

注意一下宏定义:#define MPPLNX_DUMP_READ_WRITE_CDB(x) ...

注:可重入性是指函数可以被多个任务进程调用;一个可重入的函数简单来说就是可以被中断的函数,也就是可以在这个函数执行的任何时刻中断它,OS调度转入去执行另外一段代码,而返回控制时不会出现错误;而不可重入的函数由于使用了一些系统资源,比如全局变量区,中断向量表等,所以它如果被中断的话,可能会出现问题。

满足下列条件的函数多数是不可重入的:

1) 函数体内使用了静态的数据结构;

2) 函数体内调用了malloc()或者free()函数;

3) 函数体内调用了标准I/O函数。

4、语句结构上,涉及有意义的常量,应当用枚举或宏来代替;常量放在变量的左边;用小括号来体现优先级。<<等逻辑关键字前后加空格。函数功能应当单一。

输入参数的合法性检查:

1)外部模块或者用户输入的参数;

2)从物理链路上接收到的数据。

5、可测性上,代码自始至终只有一份,不存在开发版本和测试版本;测试与最终发行的版本是通过编译开关的不同来实现,编译开关要规范统一。

使用断言来发现软件问题;注意:在Release版本下,assert被定义成空操作(不执行),所以如下写法是不对的:assert(E1T1_OK == E1T1_SetDefaultFramingMode());

6、程序效率上,循环体内工作量最小化,被信号量保护的区域应该尽可能小。

7、质量上,内存分配上,一般秉承谁申请,谁释放,也样:文件句柄;尤其是有异常退出的地方。内存释放后,一定要把指针置为NULL

内存越界问题。

Unix下,多线程的中的子线程退出必需采用主动退出方式,即子线程应return出口。

不要滥用不等于禁止使用。goto使用的注意事项:

• Single entry, single exit? – use goto

• Don’t use more than one goto labels

• Use goto’s that go forward, not backward

• Make sure a goto doesn’t create unreachable code

用宏定义表达式时,要使用完备的括号;参数可能发生变化的表达式不要使用宏。

8、类属性的声明应按照如下顺序常量 -> 静态变量 -> 非静态变量public -> protected -> private

目录
相关文章
|
1月前
|
自然语言处理 算法 Java
C/C++ 程序员编程规范之注释
C/C++ 程序员编程规范之注释
40 1
|
1月前
|
程序员 开发工具 C++
C/C++ 程序员编程规范之排版
C/C++ 程序员编程规范之排版
31 1
|
8月前
|
编译器 C++
【C++】实用编程规范与建议
C++ 相关,比较实用的 防止疏漏出错的编码规范与编码建议
111 0
|
9月前
|
存储 设计模式 算法
03-📝C++核心语法|面向对象1【 C++编程规范、类和对象、面向对象程序设计案例、对象的构造和析构、C++面向对象模型初探】
复习`C++核心语法`,且适当进行汇编探索底层实现原理,进一步夯实基础,为以后的`底层开发`、`音视频开发`、`跨平台开发`、`算法`等方向的进一步学习埋下伏笔。
03-📝C++核心语法|面向对象1【 C++编程规范、类和对象、面向对象程序设计案例、对象的构造和析构、C++面向对象模型初探】
|
程序员 C++ C语言
《C++编程规范:101条规则、准则与最佳实践》——导读
许多糟糕的编程规范都是由一些没有很好地理解语言、没有很好地理解软件开发或者试图标准化过多东西的人制定的。糟糕的编程规范会很快丧失可信度,如果程序员不喜欢或者不同意其中一些糟糕的准则,那么即使规范中有一些合理的准则,也可能被不抱幻想的程序员所忽略,这还是最好的情况,最坏的情况下,糟糕的标准可能真会被强
1770 0