《高质量C/C+编程指南》第2期

痛定思痛。 2023-10-05 22:35 12阅读 0赞

![01a04cc52cfd404a995b6f98090689a9.gif][]

**目录**

一、命名规则

1.共性规则

2.简单的Windows应用程序命名规则

3.简单的Unix应用程序命名规则

二、表到式和基本语句

1.运算符的优先级

2.复合表达式

3.if语句

4.循环语句的效率

5.for语句的循环控制变量

6.switch语句

7.goto语句

--------------------

### 一、命名规则 ###

比较著名的命名规则当推  Microsoft  公司的“**匈牙利**”法，该命名规则的主要思想 是“**在变量和函数名中加入前缀以增进人们对程序的理解**”。例如所有的字符变量均以 ch 为前缀，若是指针变量则追加前缀 p。如果一个变量由 ppch 开头，则表明它是指向 字符指针的指针。

> “匈牙利”法最大的缺点是烦琐，例如 
> 
> int i, j, k; 
> 
> float x, y, z;

倘若采用“匈牙利”命名规则，则应当写成

int iI, iJ, ik; // 前缀 i 表示 int 类型
    float fX, fY, fZ; // 前缀 f 表示 float 类型

如此烦琐的程序会让绝大多数程序员无法忍受。 据考察，没有一种命名规则可以让所有的程序员赞同，程序设计教科书一般都不指 定命名规则。命名规则对软件产品而言并不是“成败悠关”的事，我们不要化太多精力 试图发明世界上最好的命名规则，而应当制定一种令大多数项目成员满意的命名规则， 并在项目中贯彻实施

#### 1.共性规则 ####

本节论述的共性规则是被大多数程序员采纳的，我们应当在遵循这些共性规则的前

提下，再扩充特定的规则 。

**【规则 1】**

标识符应当直观且可以拼读，可望文知意，不必进行“解码”。 标识符最好采用英文单词或其组合，便于记忆和阅读。切忌使用汉语拼音来命名。 程序中的英文单词一般不会太复杂，用词应当准确。例如不要把 CurrentValue  写成

NowValue 。

**【规则 2】**

标识符的长度应当符合“min-length && max-information”原则。 几十年前老 ANSI C  规定名字不准超过  6  个字符，现今的 C++/C 不再有此限制。一 般来说，长名字能更好地表达含义，所以函数名、变量名、类名长达十几个字符不足为 怪。那么名字是否越长约好？不见得! 例如变量名 maxval 就比 maxValueUntilOverflow 好用。单字符的名字也是有用的，常见的如 i,j,k,m,n,x,y,z等，它们通常可用作函数 内的局部变量。

**【规则 3】**

命名规则尽量与所采用的操作系统或开发工具的风格保持一致。 例如 Windows  应用程序的标识符通常采用“大小写”混排的方式，如  AddChild 。 而 Unix  应用程序的标识符通常采用“小写加下划线”的方式，如  add\_child。别把这类风格混在一起用。

**【规则 4】**

程序中不要出现仅靠大小写区分的相似的标识符。

例如：

int x, X; // 变量 x 与 X 容易混淆
    void foo(int x); // 函数 foo 与 FOO 容易混淆
    void FOO(float x);

**【规则 5】**

程序中不要出现标识符完全相同的局部变量和全局变量，尽管两者的 作用域不同而不会发生语法错误，但会使人误解。

**【规则 6】**

变量的名字应当使用“名词”或者“形容词＋名词”。

例如：

float value;
    float oldValue;
    float newValue;

**【规则 7】**

全局函数的名字应当使用“动词”或者“动词＋名词”（动宾词组）。 类的成员函数应当只使用“动词”，被省略掉的名词就是对象本身。

例如：

DrawBox(); // 全局函数
    box->Draw(); // 类的成员函数

**【规则 8】**

用正确的反义词组命名具有互斥意义的变量或相反动作的函数等。

例如：

int minValue;
    int maxValue;
    int SetValue(…);
    int GetValue(…);

**【建议 1】**

尽量避免名字中出现数字编号，如 Value1,Value2 等，除非逻辑上的 确需要编号。这是为了防止程序员偷懒，不肯为命名动脑筋而导致产生无意义的名 字（因为用数字编号最省事）。

#### 2.简单的Windows应用程序命名规则 ####

作者对“匈牙利”命名规则做了合理的简化，下述的命名规则简单易用，比较适合 于 Windows  应用软件的开发。

**【规则 1】**

类名和函数名用大写字母开头的单词组合而成。

例如：

class Node; // 类名
    class LeafNode; // 类名
    void Draw(void); // 函数名
    void SetValue(int value); // 函数名

**【规则 2】**

变量和参数用小写字母开头的单词组合而成。

例如：

BOOL flag;
    int drawMode;

**【规则 3】**

常量全用大写的字母，用下划线分割单词。

例如：

const int MAX = 100;
    const int MAX_LENGTH = 100;

**【规则 4】**

静态变量加前缀  s\_ （表示  static ）。

例如：

void Init(…)
    {
         static int s_initValue; // 静态变量
         …
    }

**【规则 5】**

如果不得已需要全局变量，则使全局变量加前缀  g\_ （表示  global ）。

例如：

int g_howManyPeople; // 全局变量
    int g_howMuchMoney; // 全局变量

**【规则 6】**

类的数据成员加前缀  m\_ （表示  member ），这样可以避免数据成员与  成员函数的参数同名。

例如：

void Object::SetValue(int width, int height)
    {
         m_width = width;
         m_height = height;
    }

**【规则**  **7** **】**

为了防止某一软件库中的一些标识符和其它软件库中的冲突，可以为  各种标识符加上能反映软件性质的前缀。例如三维图形标准  OpenGL  的所有库函数  均以  gl  开头，所有常量（或宏定义）均以  GL  开头。

#### 3.简单的Unix应用程序命名规则 ####

### 二、表到式和基本语句 ###

读者可能怀疑：连 if、for、while、goto、switch 这样简单的东西也要探讨编程 风格，是不是小题大做？ 我真的发觉很多程序员用隐含错误的方式写表达式和基本语句，我自己也犯过类似

的错误。 表达式和语句都属于 C++/C 的短语结构语法。它们看似简单，但使用时隐患比较多。

本章归纳了正确使用表达式和语句的一些规则与建议。

#### 1.运算符的优先级 ####

C++/C  语言的运算符有数十个，运算符的优先级与结合律如表  4-1  所示。注意一元运算符 + - \*  的优先级高于对应的二元运算符。

![8fa519bdbcd4416e9fc0c2c46c71990c.png][]

**【规则 1】**

如果代码行中的运算符比较多，用括号确定表达式的操作顺序，避免

使用默认的优先级。

由于将表  4-1  熟记是比较困难的，为了防止产生歧义并提高可读性，应当用括号确

定表达式的操作顺序。

例如：

word = (high << 8) | low 
    if ((a | b) && (a & c))

#### 2.复合表达式 ####

如  a = b = c = 0  这样的表达式称为复合表达式。

允许复合表达式存在的理由是：

**（1） 书写简洁；**

**（2）可以提高编译效率。但要防止滥用复合表达式。**

**【规则 1** **】**

不要编写太复杂的复合表达式。

例如：

i = a >= b && c < d && c + f <= g + h ; // 复合表达式过于复杂

**【规则 2】**

不要有多用途的复合表达式。

例如：

d = (a = b + c) + r ;

该表达式既求 a 值又求 d 值。

应该拆分为两个独立的语句：

a = b + c;
    d = a + r;

**【规则 3】**

不要把程序中的复合表达式与“真正的数学表达式”混淆。

例如：

if (a < b < c) // a < b < c 是数学表达式而不是程序表达式

并不表示

if ((a<b) && (b<c))

而是成了令人费解的

if ( (a<b)<c )

####  ####

#### 3.if语句 ####

if 语句是 C++/C 语言中最简单、最常用的语句，然而很多程序员用隐含错误的方式 写 if 语句。本节以“与零值比较”为例，展开讨论。

1.布尔变量与零值比较

**【规则 1】**

不可将布尔变量直接与  **TRUE、FALSE 或者 1、0**  **进行比较**。 根据布尔类型的语义，**零值为“假”（记为 FALSE** **），任何非零值都是“真”（记为 TRUE）**。 TRUE  的值究竟是什么并没有统一的标准。例如  **Visual C++ 将 TRUE**  **定义为 1**，而  **Visual Basic 则将 TRUE 定义为\-1** 。 假设布尔变量名字为 flag，它与零值比较的标准 if  语句如下： **if (flag) // 表示 flag 为真**

if (!flag) // 表示 flag 为假

其它的用法都属于不良风格，例如：

if (flag == TRUE)
    if (flag == 1 )
    if (flag == FALSE)
    if (flag == 0)

2.整型变量与零值比较

**【规则 2】**

应当将整型变量用“==”或“！=”直接与 0 比较。

假设整型变量的名字为 value，它与零值比较的标准  if  语句如下：

if (value == 0)
    if (value != 0)

不可模仿布尔变量的风格而写成

if (value) // 会让人误解 value 是布尔变量
    if (!value)

3. 浮点变量与零值比较

**【规则 3】**

不可将浮点变量用“==”或“！=”与任何数字比较。 千万要留意，无论是 float 还是 double 类型的变量，都有精度限制。所以一定要 避免将浮点变量用“==”或“！=”与数字比较，应该设法转化成“>=”或“<=”形式。

假设浮点变量的名字为 x，应当将

if (x == 0.0) // 隐含错误的比较

转化为

if ((x>=-EPSINON) && (x<=EPSINON))

其中 EPSINON 是允许的误差（即精度）。

4.指针变量与零值比较

**【规则 4】**

应当将指针变量用“==”或“！=”与 NULL 比较。

指针变量的零值是“空”（记为 NULL）。尽管 NULL 的值与 0 相同，但是两者意义不

同。假设指针变量的名字为 p，它与零值比较的标准  if  语句如下：

if (p == NULL) // p 与 NULL 显式比较，强调 p 是指针变量
    if (p != NULL)

不要写成

if (p == 0) // 容易让人误解 p 是整型变量
    if (p != 0)

或者

if (p) // 容易让人误解 p 是布尔变量
    if (!p)

5. 对 if 语句的补充说明

有时候我们可能会看到 if (NULL == p) 这样古怪的格式。不是程序写错了，是程序员为了防止将 if (p == NULL) 误写成 if (p = NULL)，而有意把 p 和 NULL 颠倒。编译器认为 if (p = NULL) 是合法的，但是会指出 if (NULL = p)是错误的，因为 NULL不能被赋值。程序中有时会遇到 if/else/return的组合，应该将如下不良风格的程序

if (condition)
    return x;
    return y;

改写为

if (condition)
    {
        return x;
    }
    else
    {
        return y;
    }

或者改写成更加简练的

return (condition ? x : y);

#### 4.循环语句的效率 ####

C++/C 循环语句中，for 语句使用频率最高，while 语句其次，do 语句很少用。本 节重点论述循环体的效率。提高循环体效率的基本办法是降低循环体的复杂性。

**【建议 1】**

在多重循环中，如果有可能，应当将最长的循环放在最内层，最短的 循环放在最外层，以减少 CPU 跨切循环层的次数。例如示例 4-4(b)的效率比示例4-4(a)的高。

![ed7c980e5e9f4c24aaa8e83fb7d15bd0.png][]

**【建议**  **2** **】**

如果循环体内存在逻辑判断，并且循环次数很大，宜将逻辑判断移到循环体的外面。示例 4-4(c)的程序比示例 4-4(d)多执行了 N-1 次逻辑判断。并且 由于前者老要进行逻辑判断，打断了循环“流水线”作业，使得编译器不能对循环 进行优化处理，降低了效率。如果 N 非常大，最好采用示例 4-4(d)的写法，可以提 高效率。如果 N 非常小，两者效率差别并不明显，采用示例 4-4(c)的写法比较好，因为程序更加简洁。

![7a182ae4646449588e88eab376acc9c2.png][]

#### 5.for语句的循环控制变量 ####

**【规则**  **1** **】**

不可在  for  循环体内修改循环变量，防止  for  循环失去控制。

**【建议**  **1** **】**

建议 for 语句的循环控制变量的取值采用“半开半闭区间”写法。 示例 4-5(a)中的 x 值属于半开半闭区间“0 =< x < N”，起点到终点的间隔为 N， 循环次数为 N。 示例 4-5(b)中的 x 值属于闭区间“0 =< x <= N-1”，起点到终点的间隔为 N-1，循 环次数为 N。 相比之下，示例 4-5(a)的写法更加直观，尽管两者的功能是相同的。

![c3df2ce067264a3f81cbe6e1d86be620.png][]

#### 6.switch语句 ####

有了 if 语句为什么还要 switch 语句？ switch 是多分支选择语句，而 if 语句只有两个分支可供选择。虽然可以用嵌套的 if 语句来实现多分支选择，但那样的程序冗长难读。这是 switch 语句存在的理由。

switch 语句的基本格式是：

switch (variable)
    {
      case value1 : …
      break;
      case value2 : …
      break;
    
      …
      default : …
      break;
    }

**【规则**  **1** **】**

每个 case 语句的结尾不要忘了加 break，否则将导致多个分支重叠  （除非有意使多个分支重叠）。

**【规则 2】**

不要忘记最后那个 default 分支。即使程序真的不需要 default 处理，  也应该保留语句 default : break; 这样做并非多此一举，而是为了防止别人误以  为你忘了 default 处理。

#### 7.goto语句 ####

自从提倡结构化设计以来，goto 就成了有争议的语句。首先，由于 goto 语句可以

灵活跳转，如果不加限制，它的确会破坏结构化设计风格。其次，goto 语句经常带来错

误或隐患。它可能跳过了某些对象的构造、变量的初始化、重要的计算等语句，例如：

goto state;
    String s1, s2; // 被 goto 跳过
    int sum = 0; // 被 goto 跳过
    …
    state:
    …

如果编译器不能发觉此类错误，每用一次 goto 语句都可能留下隐患。 很多人建议废除 C++/C 的 goto 语句，以绝后患。但实事求是地说，错误是程序员 自己造成的，不是 goto 的过错。goto 语句至少有一处可显神通，它能从多重循环体中 咻地一下子跳到外面，用不着写很多次的 break 语句; 例如

{ …
       { …
          { …
             goto error;
          }
       }
    }
    error:
    …

就象楼房着火了，来不及从楼梯一级一级往下走，可从窗口跳出火坑。所以我们主 张少用、慎用 goto 语句，而不是禁用。

![5a08bcda916f46b18c662b12d85d63e2.gif][]

[01a04cc52cfd404a995b6f98090689a9.gif]: https://img-blog.csdnimg.cn/01a04cc52cfd404a995b6f98090689a9.gif
[8fa519bdbcd4416e9fc0c2c46c71990c.png]: https://img-blog.csdnimg.cn/8fa519bdbcd4416e9fc0c2c46c71990c.png
[ed7c980e5e9f4c24aaa8e83fb7d15bd0.png]: https://img-blog.csdnimg.cn/ed7c980e5e9f4c24aaa8e83fb7d15bd0.png
[7a182ae4646449588e88eab376acc9c2.png]: https://img-blog.csdnimg.cn/7a182ae4646449588e88eab376acc9c2.png
[c3df2ce067264a3f81cbe6e1d86be620.png]: https://img-blog.csdnimg.cn/c3df2ce067264a3f81cbe6e1d86be620.png
[5a08bcda916f46b18c662b12d85d63e2.gif]: https://img-blog.csdnimg.cn/5a08bcda916f46b18c662b12d85d63e2.gif