第一章 风格

一.风格

1.0 引子

    对于一门编程语言，使用其进行代码的编写，不仅仅要让计算机“读懂”，更是要让其他程序员读懂。因此，好的程序就像一篇好的作文，语句凝练，段落清晰。反映到程序上，则是程序要有一个良好的风格。而好的风格在代码的维护与修改上都会给之后的工作带来极大的便利。

1.1 名字

    形式上，一个变量的名字应该遵循着简练、易记忆。当然，如果使用英文进行注明则是再好不过。

    对于不同种类的变量，如果你应用了全局变量（当然我不推荐使用全局变量，尤其在大工程时候），那么全局变量的名称应该越详尽越好，确保每个人都能知道这个变量所代表的。当然，给予全局变量一个注释也是很好的

    对于一些特定的变量，我们一般有一些约定俗成的规定：

    指针：p结尾的变量名（model_p）

    全局变量：大写的首字母（Global）

    常量：全大写（CONSTANT）

    在某一个确定的类中，我们则使用简化过的变量命名方式，例如：

class User
{
	int item, sequence...;
	//而不是 int User_item...
}

    那么在使用这个类的时候，我们就可以

User user;
user.item = ...;
//而不是user.User_item = ...（显得多余）

1.2表达式和语句

    为了使你的代码更加易于理解，方便阅读，我们一般推荐使用格式化的方法来进行代码的书写。这些类似于“整理桌面”的小事往往可以在你改bug的时候发挥巨大的能量。    当我们在写表达式的时候，我们要让我们的表达式可以被我们大声的念出来

if(!(block_id < act) || !(block_id >= unb)) 
//明显不是一个好的表达式

    而当我们进行一下修改

if((block_id >= act) || (block_id < unb)) 
//一个好的表达式

    这就清楚多了
    对于C和C++来讲，多写几个括号总不是坏处，因为绝大多数情况下，我们搞不清楚到底优先级是什么样的。
    对于C和C++来讲，多写几个括号总不是坏处，因为绝大多数情况下，我们搞不清楚到底优先级是什么样的。

    而另一个需要注意的地方就是，C代码不是要你“炫技”，而是写出好懂的程序，混乱、长的表达式会产生和你想的完全相反的结果（过一阵子你自己可能都不懂了），例如下面这个：

sub = sub >> ( bit - ((bit >> 3) << 3));

1.3一致性与习惯用法

    例如循环的时候，我们使用下标的方式应该保持相同，例如一直都为从上到下或者从下到上；字符串复制的时候保持用库函数或者是for循环，稳定的代码（对于某一种操作）将会使程序更加的清楚。

    补充一点：strlen在计算字符串时并没有计算结尾的"\0"，而strcpy则会复制它，所以我们在分配字符空间的时候，要使用：

p = malloc(strlen(buf) + 1)
strcpy(p, buf)

    这种形式。如果你忘了+1，那么就要当心了。

    对于if-else这种常见判断语句，我们应竭力避免嵌套结构的发生，也就是要避免

if (...)
	{
		...
		if (...)
		{
			...
			if (...)
			{
				...
			}
			else
			{
				...
			}
		}
		else
		{
			...
		}
	}
	else
	{
		...
	}

    以上这种结构的出现，而是要争取做到以下这种

if (...)
	{
		...
	}
	else if (...)
	{
		...
	}
	else
	{
		...
	}

    这样的结构。因为下面这样的结构将会使你的思路(不论读程序还是写程序)都十分清晰。

1.4函数宏

    到目前为止，随着计算速度的快速增加，新机器和编译程序的不断出现。函数宏的缺点也就远远超出了它的优点。当然，如果一定要使用函数宏这个东西，那一定要特别小心。一个简单的例子就是：

    当你把square()设置为一个函数的时候，计算1/square(x)将不会有任何问题，但是你如果将square设置为函数宏

    #define square(x) (x) * (x)

    看着好像没什么问题，但是如果执行1/square(x)，你将会得到

    (1/(x)) * (x)这么一个尴尬的结果，而一般来讲，你完全发现不了到底是哪里错了。

    这是因为，宏是通过文本替换方式实现的：定义体里的参数被调用的实际参数替换，得到的结果再作为文本去替换原来的调用段。这种做法与函数不同，常给我们带来上述的麻烦。

1.5神秘的数

    神秘的数包括各种常数、数组的大小、字符位置、变换因子以及程序中出现的其他以文字形式写出的数值。在一个程序中，我们不可避免的要使用到一些常量或是定义的数据，而这些数据可能导致我们的程序对以后的修改、代码的共享非常的不友好。因为出现在代码段中的自定义数据很少有人能记住都代表着什么。

    而对于这样的情况，一般推荐使用enum枚举类型来对各种常量进行定义，并使用注释注解变量的含义。

    我们还是不推荐使用宏常量，因为宏常量将会在背地里改变词法结构，造成一些很奇怪的错误。

    一个简单的例子就是：

enum
	{
		...   /**/
		...   /**/
	};

    当然，枚举类型只能在整数(且整数类型相同时候(Integer或Long)时可以使用)，对于小数来讲，我们一般使用const类型常量来进行定义。

1.6注释

    注释是帮助程序读者的一种手段。但是，如果在注释中只说明代码本身已经讲明的事情，或者与代码矛盾，或是以精心编排的形式干扰读者，那么它们就是帮了倒忙。最好的注释是简洁地点明程序的突出特征，或是提供一种概观，帮助别人理解程序。

    好的注释会把散布在代码中的信息收集到一起，或者帮助澄清难以理解的情况。

    而注释最应该被看到的地方，一般是函数、全局变量、常数定义、结构和类的域等。当然，注释那些逻辑比较复杂的地方，也可以让你的代码被人理解的很好。

    另外值得注意的是，重写那些比较差的代码，而不是尝试去注释它。当你的注释比代码还长的时候，那基本上就要意味着你要重写这段代码了。

    注释还在一个位置很有用处，那就是很平常的函数却有着不一样的用法的时候。例如说strcmp，大家都知道这是一个大小比较函数，但是如果我们用

int m = strcmp(str1, str2);

    那么我们就不是那么容易的理解到这个函数到底返回的是什么了，这时的注释将会是很有必要的。

1.7结语

    我们使用原书的语句进行结尾，它出自Rob等人编写的《程序设计实践》一书：

    我们的回答是：书写良好的代码更容易阅读和理解，几乎可以保证其中的错误更少。进一步说，它们通常比那些马马虎虎地堆起来的、没有仔细推敲过的代码更短小。在这个拼命要把代码送出门、去赶上最后期限的时代，人们很容易把风格丢在一旁，让将来去管它们吧。但是，这很可能是一个代价非常昂贵的决定。草率的代码是很坏的代码，它不仅难看、难读，而且经常崩溃。

    这里最关键的结论是：好风格应该成为一种习惯。如果你在开始写代码时就关心风格问题，如果你花时间去审视和改进它，你将会逐渐养成一种好的编程习惯。一旦这种习惯变成自动的东西，你的潜意识就会帮你照料许多细节问题，甚至你在工作压力下写出的代码也会更好。