谈谈为 Linux 内核写驱动的编码规范.docx

谈谈为 Linux 内核写驱动的编码规范最近在向Linux内核提交一些驱动程序，在提交的过程中，发现自己的代码离Linux内核 的coding style要求还是差很多。当初自己对内核文档里的CodingStyle一文只是粗略的浏览，真正写代码的时候在很多细节上会照顾不周。不过，?在不遵 守规则的程序员队伍里，我并不是孤独的。如果去看drivers/staging下的代码，就会发现很多驱动程序都没有严格遵守内核的coding style，而且在很多驱动程序的TODO文件里，都会把checkpatch.pl fixes作为自己的目标之一（checkpatch.pl是用来检查代码是否符合coding style的脚本）。不可否认，coding style是仁者见仁、智者见智的事情。比如Microsoft所推崇的匈牙利命名法，在Linus看来就是及其脑残(brain damaged)的做法。也许您并不赞成Linus制定的coding style，但在提交内核驱动这件事上，最好还是以大局为重。对于这么一个庞大的集市式的开发来说，随意书写代码必将带来严重的可维护性的灾难。（题图来自：mota.ru）一些辅助工具当代码量达到一定程度时，手动去检查和修改coding style是非常繁琐的工作，幸好，我们还有一些工具可以使用。scripts/checkpatch.pl这是一个检查代码是否符合内核编码规范的的脚本。顾名思义，checkpatch是用来检查patch的，默认的调用也确实如此。如果用来检查原文件，需要加上“-f”的选项。我们来看一段无聊的代码(文件名为print_msg.c)：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.c检查的结果是：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 checkedswitch.c has style problems, please review. If any of these errorsare false positives report them to the maintainer, seeCHECKPATCH in MAINTAINERS.在Linux内核的coding style里，switch和case要求有相同的缩进。本例的代码很少，错误也只有这一个，手动修改很方便。如果类似的缩紧错误很多怎么办？scripts/Lindentscripts目录下的工具Lindent可以用来自动修改缩进问题。提醒一下，使用Lindent要求系统安装indent这个工具。对于上面这个例子，执行Lindent命令：scripts/Lindentprint_msg.c得到的新代码是：void print_msg(int a){ switch (a) { case 1:printf(a == 1\n); break; case 2:printf(a == 2\n); break; }}sedsed是一个流编辑器，其强大的功能可以帮助我们处理很多重复性的工作。比如，Linux内核的coding style要求，行尾不能有空格（包括Tab），去除这些空格就可以借助sed。我自己的习惯很差，经常在代码的行尾留下一些空格。比如一行代码过长需要换行时，总是下意识的在换行的地方敲一个空格。另外，我常用的编辑器之一的Kate，为了对齐的需要，经常在空行的前面留上几个缩进的Tab（如下图）。?手动去除这些行尾的空格是一件头大的事情，但对于sed来说不过是举手之劳。命令格式如下：sed s/[ \t]*$//g your_code.c一些需要注意的代码风格缩进1、除了注释、文档和Kconfig之外，使用Tab缩进，而不是空格，并且Tab的宽度为8个字符；2、switch ... case ...语句中，switch和case具有相同的缩进（参考上文）；花括号3、花括号