Linux 内核代码风格（编译自内核documentation/CodingStyle）

realtang

1。缩进
8个字符的长度设置为缩进的长度。这样使得你的代码更加容易阅读，并且提醒你不要nest得过深。
2。断开长的行以及长的字符串
要记住我们的代码会被屏幕只有24个字符长度的终端阅读。
3。放置大括号
这方面我们遵从C程序员的老祖宗——Kernighan and Ritchie的风格。
        if (x is true) {
                we do y
        }
        do {
                body of do-loop
        } while (condition);
        if (x == y) {
                ..
        } else if (x > y) {
                ...
        } else {
                ....
        }
定义函数时是个例外，我们这样写
        int function(int x)
        {
                body of function
        }
采用这种方式的另外一个好处是，节省空间。我们不需要为单个的括号而占用一行的空间，要知道有些人会使用很小屏幕的终端观看代码，比如PDA用户。
4。命名规则
全局的变量或函数采用描述性的名字，务尽其详。而局部函数采用缩略方式加以命名。
匈牙利命名法不被推荐。
5。函数
函数的一个推荐风格是写得短小精悍，不要超过160x24这样的长度。如果你的函数特别长，你要尽可能得断开它，使它的部分功能放置在别的函数里。如果对性能要求特别明显，那么可以把分出去的函数设置为inline。
6。宏，枚举
最好都为大写，但是宏函数例外。
7。不要滥用inline
inline函数的原则是这个函数不超过三行代码，其中的例外就是函数参数中有可以在编译时就确定的常数，而你知道因为这个常数，编译器能够加以优化从而减少函数的代码。

DoDo

好像若干年前看到过一遍英文版，并最终影响了我的代码风格。蛮喜欢这种风格的

biinn

Post by realtang
1。缩进
8个字符的长度设置为缩进的长度。这样使得你的代码更加容易阅读，并且提醒你不要nest得过深。

4个字符的缩进好些，既容易阅读，又能有足够多的缩进层次。最好将TAB缩进转化为空格，这样在不同的阅读工具中都不会有问题。在vim中可以设置：
set tabstop=4
set expandtab

Post by realtang
3。放置大括号
这方面我们遵从C程序员的老祖宗——Kernighan and Ritchie的风格。
采用这种方式的另外一个好处是，节省空间。我们不需要为单个的括号而占用一行的空间，要知道有些人会使用很小屏幕的终端观看代码，比如PDA用户。

上周我就在这栽了个跟头。我要改一个很老的代码，check out 原来的代码，删掉了很多地方，然后把几个接口函数改成新的，最后代码大致是这个样子：

2.       ......
3. 10    if (system_event_start (NULL) != SYSEVT_OK )
4. 11        errlog (......);
5. 12        return ERR_CONSYSEVT;
6. 13    }
7.       ......
8. 86    system_event_stop ();
9. 87    free (...);
10. 88    return ERR_NOERR;
11. }

复制代码

注意我在改代码时把第10行最后的{删掉了，编译的错误信息是：

2. ledopd.c:86: warning: type defaults to `int' in declaration of `system_event_stop'
3. ledopd.c:86: error: conflicting types for 'system_event_stop'
4. /vobs/ggm-rel/sgw/source/build/target/include/system_event.h:186: error: previous declaration of 'system_event_stop' was here
5. ledopd.c:86: error: conflicting types for 'system_event_stop'
6. /vobs/ggm-rel/sgw/source/build/target/include/system_event.h:186: error: previous declaration of 'system_event_stop' was here
7. ledopd.c:86: warning: data definition has no type or storage class
8. ledopd.c:88: error: parse error before "return"

复制代码

我花了两个多小时在google上也没找到真正的原因。最后下班回家，第二天早上再看代码，一眼看到第10行少了个括号。。。
所以我还是把括号放到一行吧，呵呵。

biinn

受realtang版大的影响，刚刚大致看了一下 CodingStyle。竟然将支持4字符缩进的人说成是试图将PI定义成3的同类。
no comment! 呵呵。
----------
Anyway, this is only for KERNEL coding...

x11

不喜欢K＆R风格
也没必要考虑屏幕宽度只有24
支持biinn

Fixend

最恼火还是看gnu风格的代码，头痛啊。

herberteuler

Post by Fixend
最恼火还是看gnu风格的代码，头痛啊。

用 Emacs 多了以后倒觉得 GNU 风格的代码读起来最舒服了。以前我也是 K&R 和 BSD 风格的强烈支持者，但现在我喜爱 GNU 风格更甚于前两者。

另外，适合于内核的风格并不一定适合于其他的程序。我没写过内核相关的程序，可能它们并不需要太深的嵌套。但一些应用型的程序嵌套多点儿也不是坏事。如果说写程序追求的是可读性和可维护性，嵌套应该不是问题－－事实上，系统里不同部分的角色的划分比嵌套的多少更重要。

biinn

Post by herberteuler

另外，适合于内核的风格并不一定适合于其他的程序。我没写过内核相关的程序，可能它们并不需要太深的嵌套。但一些应用型的程序嵌套多点儿也不是坏事。如果说写程序追求的是可读性和可维护性，嵌套应该不是问题－－事实上，系统里不同部分的角色的划分比嵌套的多少更重要。

同意ls...

acguy

8字符缩进很占地方，特别是还要符合：
第2条，断开长的行，80字符扣除三四个缩进后没剩多少了。
第4条，有意义的变量名，如果扣掉缩进后只要写：e = (a + b) *c + d; 当然没关系，但是如果要写 acountsum = (todaysale + yesterdaysale) * averageprice + yesterdayaccountsum; 哈哈，我总是对英文缩写把握不好，为免日后想不起来，宁愿多打几个字，于是总是要分行。

biinn

所以这个文档讲的是kernel的代码风格, 很多观点不适用于应用编程.