BBS水木清华站∶精华区

发信人: vertex (lancelord), 信区: Linux
标  题: [文档] Linux内核编程风格
发信站: BBS 水木清华站 (Thu Jul 15 16:43:22 1999)

Linux 内核编程风格

                      原文出自Linux 源码/usr/src/linux/documents/

本文在http://gem.ncic.ac.cn/~xhg/documents/CodingStyle.html

谢华刚(xhg@gem.ncic.ac.cn)翻译 ,欢迎任何问题和建议.

这篇短小的文章是对Linux内核编程风格的建议. 编程风格非常的个性化,而且,我并不
想将我的观点强加给任何人,但是为了变于维护,我不得不提出这个观点.详情如下:

在最开始,我应该写出GNU 编程风格的标准而不用理会它. 不要理会他们,它只是一个
符号表情而已.

好,让我们开始吧!

            第一章: 缩进格式

Tab 是 8 个字符,于是缩进也是8个字符.有很多怪异的风格,他们将缩进格式定义为4
个字符(设置为2个字符!)的深度,这就象试图将PI定义为3一样让人难以接受.

理由是: 缩进的大小是为了清楚的定义一个块的开始和结束.特别是当你已经在计算机
前面呆了20多个小时了以后,你会发现一个大的缩进格式使得你对程序的理解更容易.

现在,有一些人说,使用8个字符的缩进使得代码离右边很近,在80个字符宽度的终端屏
幕上看程序很难受.回答是,但你的程序有3个以上的缩进的时候,你就应该修改你的程
序.

总之,8个字符的缩进使得程序易读,还有一个附加的好处,就是它能在你将程序变得嵌
套层数太多的时候给你警告.这个时候,你应该修改你的程序.

            第二章:大符号的位置

另外一个C 程序编程风格的问题是对大括号的处理. 同缩进大小不同,几乎没有什么
理由去选择一种而不选择另外一种风格,但有一种推荐的风格,它是 Kernighan 和
Ritchie的经典的那本书带来的,它将开始的大括号放在一行的最后,而将结束大括号放
在一行的第一位,如下所示:

if (x is true) {

we do y

}

然而,还有一种特殊的情况:命名函数: 开始的括号是放在下一行的第一位,如下:

int function(int x)

{

body of function

}

所有非正统的人会非难这种不一致性,但是,所有思维正常的人明白: (第一) K&R是___
对___的,(第二)如果K&R不对,请参见第一条. (:-))......另外,函数也是特殊的,不一
定非得一致.

　

需要注意的是结束的括号在它所占的那一行是空的,__除了__它跟随着同一条语句的继
续符号.如 "while"在 do-while循环中,或者"else"在if语句中.如下:

do {

body of do-loop

} while (condition);

以及

if (x == y) {

..

} else if (x > y) {

...

} else {

....

}

理由: K&R.

另外,注意到这种大括号的放置方法减小了空行的数量,但却没有减少可读性.于是,在
屏幕大小受到限制的时候,你就可以有更多的空行来写些注释了.

            第三章 : 命名系统

C是一种简洁的语言,那么,命名也应该是简洁的. 同MODULE-2以及PASCAL语言不同的
是,C程序员不使用诸如 ThisVariableIsATemporaryCounter 之类的命名方式. 一个C
语言的程序员会将之命名为"tmp",这很容易书写,且并不是那么难以去理解.

然而,当混合类型的名字不得不出现的时候,描述性名字对全局变量来说是必要的了.
调用一个名为"foo"全局的函数是很让人恼火的.

全局变量( 只有你必须使用的时候才使用它) ,就象全局函数一样,需要有描述性的命
名方式.假如你有一个函数用来计算活动用户的数量,你应该这样命名
--"count_active_users()"--或另外的相近的形式,你不应命名为"cntusr()".

有一种称为 Hungarian命名方式,它将函数的类型编码写如变量明中,这种方式是脑子
有毛病的一种表现 --- 编译器知道这个类型而且会去检查它,而这样只会迷惑程序员.
--知道为什么Micro$oft为什么会生产这么多"臭虫"程序了把!!.

局部变量的命名应该短小精悍. 假如你有一个随机的整数循环计数器,它有可能有"i",
如果没有任何可能使得它能被误解的话,将其写作"loop_counter"是效率低下的.同样
的,""tmp"可以是任何临时数值的函数变量.

如果你害怕混淆你的局部变量的名字,还有另外一个问题,就是称
function-growth-hormone-imbalance syndrome.

            第四章: 函数

函数应该短小而迷人,而且它只作一件事情. 它应只覆盖一到两个屏幕(80*24一屏),并
且只作一件事情,而且将它做好.( 这不就是UNIX 的风格吗,译者注).

一个函数的最大长度和函数的复杂程度以及缩进大小成反比. 于是, 如果你已经写了
简单但长度较长的的函数, 而且你已经对不同的情况做了很多很小的事情,写一个更长
一点的函数也是无所谓的.

然而, 假如你要写一个很复杂的函数, 而且你已经估计到假如一般人读这个函数,他可
能都不知道这个函数在说些什么,这个时候,使用具有描述性名字的有帮助的函数.

另外一个需要考虑的是局部变量的数量. 他们不应该超过5-10个, 否则你有可能会出
错. 重新考虑这个函数 , 将他们分割成更小的函数. 人的大脑通常可以很容易的记住
7件不同的事情,超过这个数量会引起混乱. 你知道你很聪明,但是你可能仍想去明白2
周以前的做的事情.

            第5章 : 注释

注释是一件很好的事情, 但是过多的注释也是危险的,不要试图区解释你的代码是注释
如何如何的好: 你应该将代码写得更好,而不是花费大量的时间去解释那些糟糕的代
码.

通常情况下,你的注释是说明你的代码做些什么,而不是怎么做的. 而且,要试图避免将
注释插在一个函数体里: 假如这个函数确实很复杂,你需要在其中有部分的注释,你应
该回到第四章看看. 你可以写些简短的注释来注明或警告那些你认为特别聪明(或及其
丑陋)的部分, 但是你必须要避免过多. 取而代之的是, 将注释写在函数前,告诉别人
它做些什么事情,和可能为什么要这样做.

            第六章 : 你已经深陷其中了.

不要着急. 你有可能已经被告之"GUN emacs" 会自动的帮你处理C 的源代码格式, 而
且你已经看到它确实如此, 但是, 缺省的情况下, 它的作用还是不尽如人意(实际上,
他们比随便敲出来的东西还要难看 - a infinite number of monkeys typing into
GNU emacs would never make a good program)

于是, 你可以要么不要使用 GUN emacs, 要么让它使用saner valules. 使用后者,你
需要将如下的语句输入到你的 .emacs文件中.

(defun linux-c-mode ()

"C mode with adjusted defaults for use with the Linux kernel."

(interactive)

(c-mode)

(c-set-style "K&R")

(setq c-basic-offset 8))

这会定义一个 M-x Linux-c-mode 的命令. 当你hacking 一个模块的时候, 如何你将
-*- linux-c -*- 输入在最开始的两行, 这个模式会自动起作用. 而且, 你也许想加
入如下

(setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode)

auto-mode-alist))

到你的.emacs文件中, 这样的话, 当你在/usr/src/linux下编辑文件的时候,它会自动
切换到linux-c-mode .

但是, 假如你还不能让emaces去自动处理文件的格式, 不要紧张, 你还有一样东西 :
"缩进" .

GNU 的缩进格式也很死板, 这就是你为什么需要加上几行命令选项. 然而, 这还不算
太坏,因为GNU 缩进格式的创造者也记得 K&R 的权威, ( GNU 没有罪, 他们仅仅是在
这件事情上错误的引导了人们) , 你要做的就只有输入选项 "-kr -i8"(表示"K&R, 缩
进8个字符).

"缩进"有很多功能, 特别是当它建议你重新格式你你的代码的时候,你应该看看帮助.
但要记住 : "缩进"不是风格很差的程序的万灵丹.

--
※ 来源:·BBS 水木清华站 bbs.net.tsinghua.edu.cn·[FROM: 162.105.138.50]