最近在向Linux内核提交一些驱动程序，在提交的过程当中，发现本身的代码离Linux内核的coding style要求仍是差不少。当初本身对内核文档里的CodingStyle一文只是粗略的浏览，真正写代码的时候在不少细节上会照顾不周。不过， 在不遵照规则的程序员队伍里，我并非孤独的。若是去看drivers/staging下的代码，就会发现不少驱动程序都没有严格遵照内核的coding style，并且在不少驱动程序的TODO文件里，都会把"checkpatch.pl fixes"做为本身的目标之一（checkpatch.pl是用来检查代码是否符合coding style的脚本）。linux
不能否认，coding style是仁者见仁、智者见智的事情。好比Microsoft所推崇的匈牙利命名法，在Linus看来就是及其脑残(brain damaged)的作法。也许您并不同意Linus制定的coding style，但在提交内核驱动这件事上，最好仍是以大局为重。对于这么一个庞大的集市式的开发来讲，随意书写代码必将带来严重的可维护性的灾难。程序员
一些辅助工具
当代码量达到必定程度时，手动去检查和修改coding style是很是繁琐的工做，幸亏，咱们还有一些工具可使用。编辑器
scripts/checkpatch.pl
这是一个检查代码是否符合内核编码规范的的脚本。顾名思义，checkpatch是用来检查patch的，默认的调用也确实如此。若是用来检查原文件，须要加上“-f”的选项。ide
咱们来看一段无聊的代码(文件名为print_msg.c)：函数
|
1
2
3
4
5
6
7
8
9
10
11
12
|
void
print_msg(
int
a)
{
switch
(a) {
case
1:
printf
(
"a == 1\n"
);
break
;
case
2:
printf
(
"a == 2\n"
);
break
;
}
}
|
这段代码的coding style是否有问题呢？用checkpatch.pl来检查一下：工具
scripts/checkpatch.pl -f print_msg.cpost
检查的结果是：ui
ERROR: switch and case should be at the same indent
#3: FILE: switch.c:3:
+ switch (a) {
+ case 1:
[...]
+ case 2:
total: 1 errors, 0 warnings, 12 lines checked
switch.c
has
style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
|
在Linux内核的coding style里，switch和case要求有相同的缩进。本例的代码不多，错误也只有这一个，手动修改很方便。若是相似的缩紧错误不少怎么办？this
scripts/Lindent
scripts目录下的工具Lindent能够用来自动修改缩进问题。提醒一下，使用Lindent要求系统安装indent这个工具。
对于上面这个例子，执行Lindent命令：
scripts/Lindent print_msg.c
获得的新代码是：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
void
print_msg(
int
a)
{
switch
(a) {
case
1:
printf
(
"a == 1\n"
);
break
;
case
2:
printf
(
"a == 2\n"
);
break
;
}
}
|
sed
sed是一个流编辑器，其强大的功能能够帮助咱们处理不少重复性的工做。好比，Linux内核的coding style要求，行尾不能有空格（包括Tab），去除这些空格就能够借助sed。
我本身的习惯不好，常常在代码的行尾留下一些空格。好比一行代码过长须要换行时，老是下意识的在换行的地方敲一个空格。另外，我经常使用的编辑器之一的Kate，为了对齐的须要，常常在空行的前面留上几个缩进的Tab（以下图）。
手动去除这些行尾的空格是一件头大的事情，但对于sed来讲不过是举手之劳。命令格式以下：
sed 's/[ \t]*$//g' your_code.c
一些须要注意的Coding Style
缩进
一、除了注释、文档和Kconfig以外，使用Tab缩进，而不是空格，而且Tab的宽度为8个字符；
二、switch ... case ...语句中，switch和case具备相同的缩进（参考上文）；
花括号
三、花括号的使用参考K&R风格。
若是是函数，左花括号另起一行：
|
1
2
3
4
|
int
function(
int
x)
{
body of function
}
|
不然，花括号紧接在语句的最后：
|
1
2
3
|
if
(x is
true
) {
we
do
y
}
|
若是只有一行语句，则不须要用花括号：
|
1
2
|
if
(condition)
action();
|
可是，对于条件语句来讲，若是一个分支是一行语句，另外一个分支是多行，则须要保持一致，使用花括号：
|
1
2
3
4
5
6
|
if
(condition) {
do_this();
do_that();
}
else
{
otherwise();
}
|
空格
四、在关键字“if, switch, case, for, do, while”以后须要加上空格，如：
|
1
|
if
(something)
|
五、在关键字“sizeof, typeof, alignof, or __attribute__”以后不要加空格，如：
|
1
|
sizeof
(
struct
file)
|
六、在括号里的表达式两边不要加空格，好比，下面是一个反面的例子：
|
1
|
sizeof
(
struct
file )
|
七、大多说的二元和三元运算符两边须要空格，如“= + - < > * / % | & ^ <= >= == != ? :”；
八、一元运算符后面不要空格，如“& * + - ~ ! sizeof typeof alignof __attribute__ defined”；
九、在前缀自增自减运算符以后和后缀自增自减运算符以前不须要空格（“++”和“--”）；
十、结构成员运算符（“.”和“->”）的两边不须要空格；
十一、行尾不须要空格；
注释
十二、使用C89的“/* ... */”风格而不是C99的“// ...”风格；
1三、对于多行注释，能够参考下例：
|
1
2
3
4
5
6
7
8
|
/*
* This is the preferred style for multi-line
* comments in the Linux kernel source code.
* Please use it consistently.
*
* Description: A column of asterisks on the left side,
* with beginning and ending almost-blank lines.
*/
|
Kconfig
1四、“config”定义下面的语句用Tab缩进，help下面的语句再额外缩进两个空格，如：
|
1
2
3
4
5
6
7
8
|
config AUDIT
bool "Auditing support"
depends on NET
help
Enable auditing infrastructure that can be used with another
kernel subsystem, such as SELinux (which requires this for
logging of avc messages output). Does not do system-call
auditing without CONFIG_AUDITSYSCALL.
|
宏
1五、多行的宏定义须要用“do .. while”封装，如：
|
1
2
3
4
5
|
#define macrofun(a, b, c) \
do
{ \
if
(a == 5) \
do_this(b, c); \
}
while
(0)
|
函数返回值
1六、函数返回值的定义最好也要遵循必定的章法。
若是函数的名称是一种动做或者命令式的语句，应该以错误代码的形式返回（一般是0表示成功，-Exxx这种形式的负数表示错误），如：
|
1
|
do_something()
|
若是函数的名称是判断语句，则返回值应该相似与布尔值（一般1表示成功，0表示错误），如：
|
1
|
something_is_present()
|
【参考资料】
（2） http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/