Linux编程风格

这篇短文是关于所推荐的 Linux 核心编程风格的。编程风格是非常个人化的，
我个人不会强迫任何人同意我的观点。不过，为了能够更好的维护程序，
我仍然认为这是最重要的。请至少考虑一下这方面的问题。

首先，我建议打印一份 GNU 的编程标准，别读，直接烧了，作为一种象征 :-)

好吧，现在开始：

第一章：缩进

Tab 是 8 个字符的，所以缩进也应该是 8 个字符。有些“异教徒们”妄图把缩进

变成 4 （甚至 2！）个字符，这简直和把圆周率定义成 3 没什么区别。

基本原则：缩进是为了清晰的标明语句块的起始。特别是当你直对这屏幕 20 个小

时后，你会发现大的缩进非常容易分辨。

有些人可能认为 8 个字符的缩进把程度段都推到了很右的位置，在 80 个字符的

屏幕上读起来太困难了。答案是：如果你需要大于 3 层的缩进，你已经走火入魔了，

马上改你的程序！

总而言之，8 个字符的缩进是程序容易阅读，而且还警告你别在函数内嵌套过深。

注意这个警告的作用。

第二章：花括号

C 语言中另一个问题是如何放置花括号。不象缩进大小的问题，没有什么太严格的

要求。不过，Kernighan 和 Ritchie 提示了我们一种较好的格式，把左括号放在

同一行的行尾，右括号放在下一行的行首。


        if (x is true) {
                we do y
        }

当然，函数声明例外，左右括号都在行首。


        int function(int x)
        {
                body of function
        }

异教徒们声称这本身就是一个矛盾，嘿嘿，不过人们都知道，(a) K&R 是对的，

(b) K&R 是对的! 毕竟你在 C 里面不可能嵌套函数。

注意，左括号这行应该没其他内容了，除非还有一个条件判断语句


        do {
                body of do-loop
        } while (condition);

and

        if (x == y) {
                ..
        } else if (x > y) {
                ...
        } else {
                ....
        }

基本原则：K&R

请注意，这种花括号的放置方法减少了空行但并不降低可读性。空行对一个25行的终端屏
幕是非常重要的资源，用空行来写点注释吧。

第三章：命名

C 是斯巴达人的语言，所以，你要按斯巴达人的方法起名字:-) 与 Modula-2 和 Pascal 

程序员不同，C 程序员不会使用象 ThisVariableIsATemporaryCounter 这样的“国脚步”

变量名。C 程序员就用 tmp 这个名字，写起来容易，读起来也不难。

无论如何，尽管混合大小写的名字会让人皱眉不已，全局标识符仍然要使用非常具有描述

性的名字。把一个全局函数称为 "foo()" 实在是罪大恶极。

全局变量和全局函数（你确信她们必须是全局性的吗？）必须使用具有描述性的名字。如

果你有一个函数用来计算还没死了的用户，你得给这个函数取名叫 count_active_users(), 

千万别用 cntusr()。

把函数类型嵌入到函数名中（所谓匈牙利命名法）会把你变成痴呆 —— 编译器完全可以检

查函数返回类型，这只会把程序员搞糊涂。现在不对 M$ 错误百出得程序感到惊讶了吧。

局部变量要简单扼要。如果你要用一个循环变量，就叫 i 好了。如果没什么会引起误解的

地方，把她称为 loop_counter 并不见得有什么创造性。同样，tmp 可以作为存放任何类型

的临时变量。

如果你还是害怕混淆局部变量名的话，你很可能得了“函数荷尔蒙增长失衡症”，

请看下一章。

第四章：函数

函数要短小可爱，只做一件事情。你必须把她们放在 1、2 个屏幕中（我们都知道，

ANSI 屏幕是 80x24），只完成一个工作，并且完成得漂亮。

函数的长度和复杂性、缩进程度成反比例。如果你有一个功能简单的但包含许多行

 case 语句的函数，写得长点倒问题不大。

另外，如果你的函数过于复杂，而且你怀疑一个聪明的高一学生会看不懂函数是起什

么作用的，你差不多接近长度的极限了。用一个子功能函数，取个有描述性的名字

（如果你认为会引起效率问题，你可以编译的时候使用 in-line）。

另外一个衡量函数的标准是局部变量的数量，必须不超过 5-10 个，不然的话，你可能

又犯错误了。重新考虑这个函数，把她变成一小段一小段。一般来说，人脑可以

记住 7 个不同的东西，再多可能就糊涂了。即使你认为你是不同寻常的人，仍然

有可能需要回顾你两周前的工作。

第五章：注释

注释是需要的，但是别犯注释过多的错误。千万别用注释说明你的程序是怎么工作的：

让你的程序工作得更容易理解点，花时间去解释写得很糟糕的程序是浪费时间。

一般来说，需要用注释来说明程序是干什么的，而不是说明怎么做的。同时，避免在

函数内出现注释。如果函数很复杂而你不得不在函数内部写注释的话，我看你还是回

到第四章去看看吧。你可以用些小的注释来说明你特别得意的（没准特恶心）的部分，

不过千万别太多。在函数前面用注释说明她的作用，或为什么要写这个函数。

第六章：GNU emacs

这部分是关于 GNU emacs 的，本人不会用 emacs，怕翻不好，您要是有兴趣的话，请便