例如，add work 是一个动作，那么 add_work() 返回值为0则表示成功，-EBUSY表示失败。PCI device present是一个断言，那么 pci_dev_present() 返回值为1表示成功，0表示失败。
可导出(EXPORT)的函数都应该遵守这个约定，私有(static)函数不需要，不过我建议你还是遵守。
如果返回值是一些计算结果，那么当然不需要管这些东西。一般来说，计算结果出错了就表示失败了。典型的例子就是返回一个指针：使用 NULL 或者 ERR_PTR 来表示错误。
17 不要重新发明内核宏include/linux/kernel.h 头文件里定义了一些你可以使用的宏，你应该直接使用他们，而不是重新再定义一些新的宏。例如，如果你需要计算数组长度，使用提供的宏：
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))同样地，如果你需要计算结构体中某个成员的大小，使用：
#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))如果需要，里面还有做类型检查的 min() 和 max() 宏。仔细看看头文件中还定义了那些东西，如果里面有了，你就不要在自己的代码中重新定义了。
18 多此一举的编辑器有些编辑器可以识别源文件中的配置信息，例如 emacs 可以识别这样的标记：
-*- mode: c -*-或者这样的：
/* Local Variables: compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c" End: */Vim 可以识别：
/* vim:set sw=8 noet */不要在源代码中包含任何类似的内容。每个人都有自己的编辑器配置，你的源文件不应该影响他们。
19 内联汇编在写一些与体系结构有关的代码中，你可能需要使用一些内联汇编调用CPU相关的接口或者和平台有关的功能，如果有这种需求，你大可使用汇编。但是如果C语言可以干的事，不要使用汇编。你应该尽可能地使用C语言来控制硬件。
尽可能写一些辅助函数来实现相同的功能，而不是重复地写一些相同的代码，同时记住，内联汇编也可以使用C函数的参数。
大的、重要的汇编函数应该独自写在一个 .S 文件中，并且编写对应的C头文件和函数原型，相应的函数原型应该添加 asmlinkage 关键字。
你也许需要标记某些汇编代码为 volatile，避免 gcc 误把一些汇编移除掉。一般情况下，你不需要这样干，没必要的标记会影响优化。
当一条汇编语句里包含多个指令时，每个指令分行写，并且除了最后一行外，在其他行的行末添加 \n\t 进行缩进和对齐：
asm ("magic %reg1, #42\n\t" "more_magic %reg2, %reg3" : /* outputs */ : /* inputs */ : /* clobbers */); 20 条件编译无论在哪，不要在 .c 文件中使用条件编译命令(#if, #ifdef)，这样干会导致代码可读性降低并且代码逻辑混乱。取而代之，应该在 .c 文件对应的头文件中使用这些条件编译，并且在每个 #else 分支注明对应的版本信息。
把同一个版本的所有函数都写在一个 #ifdef 中，不要在其中写一部分，而又在外部写一部分。
在 #endif 之后写上一个注释，注明这个 #ifdef 块对应的内容：
#ifdef CONFIG_SOMETHING ... #endif /* CONFIG_SOMETHING */ ReferencesThe C Programming Language, Second Edition by Brian W. Kernighan and Dennis M. Ritchie. Prentice Hall, Inc., 1988. ISBN 0-13-110362-8 (paperback), 0-13-110370-9 (hardback).
The Practice of Programming by Brian W. Kernighan and Rob Pike. Addison-Wesley, Inc., 1999. ISBN 0-201-61586-X.
GNU manuals - where in compliance with K&R and this text - for cpp, gcc, gcc internals and indent, all available from
WG14 is the international standardization working group for the programming language C, URL:
Kernel process/coding-style.rst, by greg@kroah.com at OLS 2002: