打印

预编译处理/程序格式命名

[复制链接]
923|0
手机看帖
扫描二维码
随时随地手机跟帖
跳转到指定楼层
楼主
qaz098xsw|  楼主 | 2017-8-14 13:16 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
预编译处理/程序格式命名

第九章  c/c++编译预处理
一、文件包含
#include <头文件名称>
#include "头文件名称"

第一种形式 : 用来包含开发环境提供的库头文件,它指示编译预处理器在开发环境设定的搜索路径中查找所需的头文件
第二种形式 : 用来包含自己编写的头文件,它指示编译预处理器首先在当前工作目录下搜索头文件,如果找不到再到开发环境设定的路径中查找。


内部包含卫哨和外部包含卫哨
在头文件里面使用内部包含卫哨,就是使用一种标志宏,可以放心的在同一个编译单元及其包含的头文件中多次包含同一个头文件而不会造成重复包含。如:
#ifndef _STDDEF_H_INCLUDED_
#define _STDDEF_H_INCLUDED_
...... //头文件的内容
#endif


当包含一个头文件的时候,如果能够始终如一地使用外部包含卫哨,可以显著地提高编译速度,因为当一个头文件被一个源文件反复包含多次时,可以避免多次查找和打开头文件地操作。如:
#if !defined(_INCLUDED_STDDEF_H_)
#include <stddef.h>
#define _INCLUDED_STDDEF_H_
#endif

建议外部包含卫哨和内部包含卫哨使用同一个标志宏,这样可以少定义一个标志宏。如:
#if !defined_STDDEF_H_INCLUDED_
#include <stddef.h>
#endif


头文件包含的合理顺序
在头文件中:
1、包含当前工程中所需的自定义头文件
2、包含第三方程序库的头文件
3、包含标准头文件
在源文件中:
1、包含该源文件对应的头文件
2、包含当前工程中所需的自定义头文件
3、包含第三方程序库的头文件
4、包含标准头文件

二、宏定义
1、宏定义不是c/c++语句,所以不需要使用“;”结束
2、任何宏在编译器处理阶段都只是进行简单的文本替换,不做类型检查和语法检查,这个工作留给编译器做
3、宏定义可以嵌套
4、宏不可以调试,因为宏不会进入符号表(符号表是编译器创建的,在之前宏已经消失了),即时宏替换后出了问题,编译器也会将错误定位到源程序中,而不是定位到具体的某个宏
5、程序里使用双引号括起来的字符串中即时出现了与宏同名的子串,预编译过程也不进行替换
6、定义带参数的宏时,宏名和左括号之间不能出现空格,否则使用会出问题,但是编译器不会检查这种错误
如: #define TEXT (str)#str
cout << TEXT(Hello World);  
将扩展为:
(str)#str(Hello World);  // TEXT 相当于 "(str)#str"
7、带参数的宏体和各个形参应该分别用括号括起来。
如:#define SQUARE(X)((X)*(X))
如果写成:#define SQUARE(X)X*X
那么a = SQUARE(3+5)
将被扩展为:
a = 3+5*3+5
8、不要在引用宏定义的参数列表中使用增量和减量运算符,否则将导致变量多次求值
int a = 5;
int x = SQUARE(a++);
结果为30,而不是25!因为将被扩展为:int x = ((n++)*(n++));
9、带参数的宏定义不是函数,因为没有函数调用的开销,但是其每一次扩展都会生成重复的代码,使体积变大
10、当不再使用某一个宏时,可以使用#undef来取消其定义。如:
#undef TEXT

建议:给宏添加注释时请使用块注释(/**/),而不要使用行注释,因为有些编译器可能会把宏后面的行注释理解为宏体的一部分。
不要使用宏来定义新类型,使用typedef,否则容易造成错误。


条件编译
#if, #elif和#else
#define FALG_DOS    2
#define FALG_UNIX   1
#define FALG_WIN    0
#define OS          1

#if OS == FLAG_DOS
cout << "Dos" << endl;
#elif OS == FLAG_UNIX
cout << "Unix" << endl;
#elif OS == FLAG_WIN
cout << "Win" << endl;
#endif


#ifdef 和 #ifndef
#define XYZ
...
#ifdef XYZ
DoSomthing();
#endif


#error
编译伪指令#error用于输出与平台、环境有关的信息。


#pragma
用于执行语言实现所定义的动作。
#pragma comment(lib,"user32.lib")


#和##运算符
构串操作符#只能修饰带参数的宏的形参,它将实参的字符序列(而不是实参的值)转换为字符串常量
#define STRING(x) #x #x #x
int abc = 100
STRING(abc)
结果为:
"abcabcabc"

合并操作符##将出现在其左右的字符序列合并成一个新的标识符(注意:不是字符串)
#define CLASS_NAME(name) class##name
#define MERGE(x,y) x##y##x
则宏引用:
CLASS_NAME(SysTimer)
MERGE(me,To)
将分别扩展为两个标识符:
classSysTimer
meTome
使用合并操作符##时,产生的标识符必须预先有定义,否则编译器会报“标识符未定义”的编译错误。


预定义符号常量
__LINE__  引用该符号的语句的代码行号
__FILE__  引用该符号的源文件名称
__DATE__  引用该符号的语句所在源文件被编译的日期

预定义符号常量可以被直接引用,常用来调试信息和定位异常发生的文件及代码行。


第十章 c/c++文件结构和程序版式
版权和版本的声明
(1)版权信息。
(2)文件名称,标识符,摘要。
(3)当前版本号,作者/修改者,完成日期。
(4)版本历史信息。


代码行
【规则】一行代码只做一件事情,如只定义一个变量,或只写一条语句。这样的代码容易阅读,并且方便于写注释。
【规则】if、for、while、do 等语句自占一行,执行语句不得紧跟其后。不论执行语句有多少都要加{}。这样可以防

止书写失误。

空行
【规则】在每个类声明之后、每个函数定义结束之后都要加空行。参见示例
【规则】在一个函数体内,逻揖上密切相关的语句之间不加空行,其它地方应加空行分隔
主要讲了程序的排版,版权等方面的知识,就不搬上来了。


代码行内的空格
【规则】关键字之后要留空格。象const、virtual、inline、case 等关键字之后至少要留一个空格,否则无法辨析关

键字。象if、for、while 等关键字之后应留一个空格再跟左括号‘(’,以突出关键字。
【规则】函数名之后不要留空格,紧跟左括号‘(’,以与关键字区别。
【规则】‘(’向后紧跟,‘)’、‘,’、‘;’向前紧跟,紧跟处不留空格。
【规则】‘,’之后要留空格,如Function(x, y, z)。如果‘;’不是一行的结束符号,其后要留空格,如for (initialization; condition; update)。
【规则】赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符,如“=”、“+=” “>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<”,“^”等二元操作符的前后应当加空格。
【规则】一元操作符如“!”、“~”、“++”、“--”、“&”(地址运算符)等前后不加空格。
【规则】象“[]”、“.”、“->”这类操作符前后不加空格。
【建议】对于表达式比较长的for 语句和if 语句,为了紧凑起见可以适当地去掉一些空格,如for (i=0; i<10; i++)和if ((a<=b) && (c<=d))对齐
【规则】程序的分界符‘{’和‘}’应独占一行并且位于同一列,同时与引用它们的语句左对齐。
【规则】{ }之内的代码块在‘{’右边数格处左对齐。


长行拆分
【规则】代码行最大长度宜控制在70 至80 个字符以内。代码行不要过长,否则眼睛看不过来,也不便于打印。
【规则】长表达式要在低优先级操作符处拆分成新行,操作符放在新行之首(以便突出操作符)。拆分出的新行要进行适当的缩进,使排版整齐,语句可读。


修饰符的位置
修饰符 * 和 & 应该靠近数据类型还是该靠近变量名,是个有争议的活题。
若将修饰符 * 靠近数据类型,例如:int* x; 从语义上讲此写法比较直观,即x是int 类型的指针。
上述写法的弊端是容易引起误解,例如:int* x, y; 此处y 容易被误解为指针变量。虽然将x 和y 分行定义可以避免误解,但并不是人人都愿意这样做。


注释
【规则】注释是对代码的“提示”,而不是文档。程序中的注释不可喧宾夺主,注释太多了会让人眼花缭乱。注释的花样要少。
【规则】如果代码本来就是清楚的,则不必加注释。否则多此一举,令人厌烦。
例如   i++; // i 加 1,多余的注释
【规则】边写代码边注释,修改代码同时修改相应的注释,以保证注释与代码的一致性。不再有用的注释要删除。
【规则】注释应当准确、易懂,防止注释有二义性。错误的注释不但无益反而有害。
【规则】尽量避免在注释中使用缩写,特别是不常用缩写。
【规则】注释的位置应与被描述的代码相邻,可以放在代码的上方或右方,不可放在下方。
【规则】当代码比较长,特别是有多重嵌套时,应当在一些段落的结束处加注释,便于阅读。
(以上代码抄自第二版,实在懒得抄第三版的了。。)


第十一章 c/c++应用程序命名规则
共性规则
【规则】标识符应当直观且可以拼读,可望文知意,不必进行“解码”。
【规则】标识符的长度应当符合“min-length && max-information”原则。
【规则】命名规则尽量与所采用的操作系统或开发工具的风格保持一致。
【规则】程序中不要出现仅靠大小写区分的相似的标识符。
【规则】程序中不要出现标识符完全相同的局部变量和全局变量,尽管两者的作用域不同而不会发生语法错误,但会使人误解。
【规则】变量的名字应当使用“名词”或者“形容词+名词”。
【规则】全局函数的名字应当使用“动词”或者“动词+名词”(动宾词组)。类的成员函数应当只使用“动词”,被省略掉的名词就是对象本身。
例如:
DrawBox(); // 全局函数
box->Draw(); // 类的成员函数
【规则】用正确的反义词组命名具有互斥意义的变量或相**作的函数等。
【规则】尽量避免名字中出现数字编号,如Value1,Value2 等,除非逻辑上的确需要编号。这是为了防止程序员偷懒,不肯为命名动脑筋而导致产生无意义的名字(因为用数字编号最省事)。

相关帖子

发新帖 我要提问
您需要登录后才可以回帖 登录 | 注册

本版积分规则

632

主题

842

帖子

3

粉丝