在内核代码的Documentation\CodingStyle这个文件里，写得很清楚。
首先给出网友翻译中文版的：
第 1 章： 缩进
Tabs(制表符)是8个字符的大小，因此缩进也应该是8个字符的大小。有些叛逆主张试图把缩进变成4个(甚至是2个！)字符的长度，这就好象试图把PI(案，圆周率)定义成3是一样的。
依据：缩进背后的思想是:清楚地定义一个控制块从哪里开始，到哪里结束。尤其是在你连续不断的盯了20个小时的屏幕后，如果你有大尺寸的缩进。你将更容易发现缩进的好处。
现在，有些人说8个字符大小的缩进导致代码太偏右了，并且在一个80字符宽的终端屏幕上看着很不舒服。对这个问题的回答是：如果你有超过3个级别的缩进，你就有点犯糊涂了，应当修改你的程序。
简而言之，8个字符的缩进使程序更易读，而且当你把功能隐藏的太深时，多层次的缩进还会对此很直观的给出警告。要留心这种警告信息。
第 2 章： 放置花括号
C程序中另一个要主意的就是花括号的放置。与缩进尺寸不同的是，关于如何放置花括号没有技术上的理由。但是，首选的方法是象先知Brain Kernighan和Dennis Ritchie展现的那样：把左括号放在行尾，右括号放在行首。也就是：
if (x is true) {
we do y
}
然而，还有另外一种情况，就是函数：函数应当把左右括号都放在行首。也就是：
int function(int x)
{
body of function
}
叛逆的人们所在皆有。他们说，这样会导致…嗯，不一致性(案，指函数的花括号使用与其他情况不统一)。但是所有正确思考的人都知道：(1) K&R是正确的；(2) K&R还是正确的。而且，函数与别任何东西都不一样(在C语言中你没法隐藏它)。
注意，右括号所在的行不应当有其它东西，除非跟随着一个条件判断。也就是do-while语句中的“while”和if-else语句中的“else”。象这样：
do {
body of do-loop
} while (condition);
和：
if (x == y) {
..
} else if (x > y) {
...
} else {
....
}
依据： K&R。
而且，注意这种花括号的放置减少了空行的数目，并没损害可读性。因此，当屏幕上不可以有很多空行时(试想25行的终端屏幕)，你就有更多的空行来安插注释。
第 3 章： 命名
C是一门朴素的语言，你使用的命名也应该这样。与Modula-2和Pascal程序员不同，C程序员不使用诸如 “ThisVariableIsATemporaryCounter”这样“聪明”的名字。C程序员应该叫它“tmp”，这写起来更简单，也不会更难懂。
然而，当面对复杂情况时就有些棘手，给全局变量取一个描述性的名字是必要的。把一个全局函数叫做“foo”是一种目光短浅的行为。
全局变量(只当你确实需要时才用)应该有描述性的名字，全局函数也一样。如果你有一个统计当前用户个数的函数，应当把它命名为“count_active_user()”或者简单点些的类似名称，不应该命名为“cntusr()”。
把函数类型写进函数名(即所谓的“匈牙利命名法”)简直就是大脑有问题──编译器总是知道函数的类型并且能加以检查，这种命名法只会弄糊涂程序员自己。怪不得微软总是制造充满bug的程序。
局部变量的名字应该尽量短，而且说到点子上。如果你有个普通的整型循环计数变量，应当命名为“i”。命名为“loop_counter”并不能带来任何成效，如果它不被误解的话(案，这里的言外之意是说，如果被误解就更惨了)。与此类似，“tmp”可以作为一个用来存储任何类型临时值的变量的名字。
如果你害怕弄混淆局部变量(s)的名字，你就面临着另一个问题，也叫作“函数增长荷尔蒙失调综合症”。请参考下一章。
第 4 章： 函数
函数应当短而精美，而且只做一件事。它们应当占满1或2个屏幕(就象我们知道的那样，ISO/ANSI的屏幕大小是80X24)，只做一件事并且把它做好。
一个函数的最大长度与它的复杂度和缩进级别成反比。所以，如果如果你有一个概念上简单(案，“简单”是simple而不是easy)的函数，它恰恰包含着一个很长的case语句，这样你不得不为不同的情况准备不同的处理，那么这样的长函数是没问题的。
然而，如果你有一个复杂的函数，你猜想一个并非天才的高一学生可能看不懂得这个函数，你就应当努力把它减缩得更接近前面提到的最大函数长度限制。可以使用一些辅助函数，给它们取描述性的名字(如果你认为这些辅助函数的调用是性能关键的，可以让编译器把它们内联进来，这比在单个函数内完成所有的事情通常要好些)。
对函数还存在另一个测量标准：局部变量的数目。这不该超过5到10个，否则你可能会弄错。应当重新考虑这个函数，把它分解成小片。人类的大脑一般能同时记住7个不同的东西，超过这个数目就会犯糊涂。或许你认为自己很聪明，那么请你理解一下从现在开始的2周时间你都做什么了。
第 5 章：注释
注释是有用的，但过量的注释则是有害的。不要试图在注释中解释你的代码是如何工作的：把代码是如何工作的视为一件显然的事情会更好些，而且，给糟糕的代码作注释则是在浪费时间。
通常，你愿意自己的注
阅读(748) | 评论(0) | 转发(0) |
