嵌入式开发交流网论坛

标题: 《Linux内核编码风格》官方手册最新中译本 [打印本页]
作者: 新闻曝光台    时间: 2021-6-19 10:26
标题: 《Linux内核编码风格》官方手册最新中译本
本文是翻译自内核源码的Documentation/process/coding-style.rst（最后的提交时间是 2021 年 2 月 12 日）。
网上虽然已经有很多人做了很好的翻译，但都是很早的版本，所以我还是想自己翻译一次最新的编码风格（当然，我借助了某歌翻译），让自己加深印象。
如果发现有看不懂的地方，不用怀疑，是我翻译得不对，请告诉我：lioneie@163.com。
[attach]61541[/attach]这是一个简短的文档，描述了 linux 内核的首选编码风格。 编码风格非常个人化，我不会对任何人强加我的见解，但这是我必须要维护的代码（指 Linux 内核代码）的编码风格，对于其他项目代码，我也希望使用它。 写内核代码时请至少考虑本文提出的风格。
首先，我建议打印出 GNU 编码标准，然后不要阅读。 烧掉它们，这是一个很棒的象征性动作。
无论如何，我们开始：
1) 缩进

制表符（键）是 8 个字符，因此缩进也是 8 个字符。 有一些异端做法试图使制表符变成 4 个（甚至 2 个！）字符，这类似于尝试将 PI 的值定义为 3。理由：缩进的目的是明确定义控制块的开始和结束位置。 特别是当你连续看了 20 个小时的屏幕后，如果缩进较大则作用更大（指更容易分辨缩进）。
现在，有些人会声称具有 8 个字符的缩进会使代码向右移得太远，并使得在 80 个字符的终端屏幕上难以阅读。 答案是，如果你需要三个以上的缩进级别，那么无论如何你的代码有问题了，应该修复程序。
简而言之，8 字符缩进使内容更易于阅读，并具有在嵌套函数太深时发出警告的作用。 注意该警告。
缓解switch语句中多个缩进级别的首选方法是在同一列中对齐switch及其从属case标签，而不是对case标签进行两次缩进。 例如：switch (suffix) {case 'G':case 'g': mem 除非要隐藏某些内容，否则不要在一行上放置多个语句：
if (condition) do_this;do_something_everytime;不要使用逗号来避免使用花括号：
if (condition) do_this, do_that;始终对多个语句使用花括号：
if (condition) { do_this; do_that;}也不要将多个赋值语句放在一行上。 内核编码风格非常简单。 避免使用棘手的表达式。
除了注释，文档和 Kconfig 外，空格都不用于缩进，前面的例子是故意的。
选用一个好的编辑器，不要在行尾留空格。
编码风格是关于使用通用工具来维持可读性和可维护性。
单行长度的首选限制是 80 列。
长度超过 80 列的语句应分为合理的片段，除非超过 80 列会显着提高可读性且不会隐藏信息。
后面的片段应该短于原来的语句，并且基本上位于靠右放置。 一个典型的例子是将后面的片段与函数左括号对齐。
这些相同的规则适用于带有长参数列表的函数头，如下所示：
/* 注意：这个例子是我（陈孝松）写的 */void func(int a, int b, int c, int d, int e, int f, int g, int h, int iint j, int k){ ...｝但是，切勿破坏诸如printk消息之类的用户可见的字符串，因为这会破坏grep为它们显示的功能。3) 大括号和空格的放置

3.1) 大括号

C 样式中经常出现的另一个问题是大括号的位置。 与缩进尺寸不同，没有什么技术上的原因可以选择一种放置策略而不是另一种，但是正如 Kernighan 和 Ritchie 向我们展示的，首选方式是将起始大括号放在行尾，然后将结束大括号放在行首，所以：
if (x is true) { we do y}这适用于所有非函数语句块（if、switch、for、while、do）。 例如：switch (action) {case KOBJ_ADD: return "add";case KOBJ_REMOVE: return "remove";case KOBJ_CHANGE: return "change";default: return NULL;}但是，有一个特殊情况，即函数：在下一行的开头放置起始大括号，因此：
int function(int x){ body of function}全世界的异端人士都声称这种不一致性是……嗯……是不一致的，但是所有思维健全的人都知道（a）K＆R 是正确的，（b）K＆R 是正确的。 此外，函数是很特殊的（在 C 语言中函数是不能嵌套的）。
陈孝松注：K & R：《The C Programming Language》一书的作者 Kernighan 和 Ritchie。
请注意，结束大括号单独一行，除非在其后跟着同一条语句的剩余部分，也就是do语句中的while，或者if语句中的else，例如：do { body of do-loop} while (condition);还有
if (x == y) { ..} else if (x > y) { ...} else { ....}理由：K＆R。
另外，请注意，这种大括号的放置方式还可以最大程度地减少空（或几乎空）行的数量，而不会损失任何可读性。 因此，由于屏幕上的新行是不可再生资源（请考虑 25 行的终端屏幕），因此你有更多的空行可以放置注释。
在单个语句使用的地方，不用加不必要的大括号。
if (condition) action;和
if (condition) do_this;else do_that;如果条件语句的只有一个分支是单个语句，则不适用； 这时请在两个分支中都使用大括号：
if (condition) { do_this; do_that;} else { otherwise;}另外，当循环中包含了多个单行的简单语句时，请使用大括号：
while (condition) { if (test) do_something;}3.2) 空格

Linux 内核使用空格的方式（主要）取决于是用于函数还是关键字。 （大多数）在关键字之后加一个空格。 值得注意的例外是sizeof、typeof、alignof和attribute，它们看起来有点像函数（并且在 Linux 中通常与小括号一起使用，尽管它们在语言中不是必需的，例如：struct fileinfo info;声明后的sizeof info） 。因此，在这些关键字之后加一个空格：
if, switch, case, for, do, while但不能在sizeof、typeof、alignof或attribute之后加空格。 例如：s = sizeof(struct file);不要在小括号的表达式两侧（内部）添加空格。 这是反例：
s = sizeof( struct file );在声明指针数据类型或返回指针类型的函数时，*的首选用法是与数据名称或函数名称相邻，而不与类型名称相邻。 例子：char *linux_banner;unsigned long long memparse(char *ptr, char **retptr);char *match_strdup(substring_t *s);在大多数二元和三元运算符的两侧（每边）使用一个空格，例如以下任意一个：
但一元运算符后不要加空格：
& * + - ~ ! sizeof typeof alignof __attribute__ defined后缀递增和递减一元运算符前没有空格：
++ --前缀递增和递减一元运算符后没有空格：
++ --.结构成员操作符前后没有空格。不要在行尾留空格。 某些具有“智能”缩进的编辑器将在适当的情况下在新行的开头插入空格，因此你可以立即开始键入下一行代码。 但是，如果没有在这一行输入代码，则某些编辑器不会删除空格，就像你留下一个只有空白的行。 结果，行尾带有空格的行就产生了。
当 git 发现补丁包含了行尾空格的时候会警告你，并且可以有选择地为你去掉尾随空格； 但是，如果打一系列补丁，这样做会导致后面的补丁失败，因为你改变了补丁的上下文。
4) 命名

C 是一种简朴的语言，你的命名也应是这样。 与 Modula-2 和 Pascal 程序员不同，C 程序员不会使用诸如ThisVariableIsATemporaryCounter之类的可爱名称。 C 程序员将该变量命名为tmp，该变量更容易编写，而且更容易理解。但是，虽然不赞成使用大小写混合的名称，但全局变量还是需要使用具备描述性的名称。 把全局函数命名为foo是一种难以饶恕的错误。全局变量（仅在确实需要它们时才使用）与全局函数一样，都需要具有描述性名称。 如果你有一个统计活动用户数量的函数，则应命名为count_active_users或类似名称，而不应该命名为cntusr。在函数名中包含函数类型（所谓的匈牙利命名法）是愚蠢的 - 编译器知道类型而且能够检查类型，这样做只能把程序员弄糊涂。
陈孝松注：这里曾经还有一句话：难怪微软总是制造出有问题的程序。在 2021 年 2 月 12 日这句话被删除了。
局部变量名称应简短明了。 如果你有一些随机整数循环计数器，则应命名为i。 如果没有可能被误解，则命名为loop_counter是无用的。 同样，tmp可以用来命名任意类型的临时变量。如果你害怕混淆你的局部变量名称，那么你会遇到另一个问题，称为叫做函数增长荷尔蒙失衡综合症function-growth-hormone-imbalance syndrome。 请参见第 6 章（函数）。
对于符号名称和文档，请避免引入“主/从”（或独立于“主”的“从”）和“黑名单/白名单”的新用法。
推荐的“主master/从slave”替代方案是：
'{primary,main} / {secondary,replica,subordinate}' '{initiator,requester} / {target,responder}' '{controller,host} / {device,worker,proxy}' 'leader / follower' 'director / performer'推荐的“黑名单blacklist/白名单whitelist”替代方案是：
'denylist / allowlist' 'blocklist / passlist'引入新用法的例外情况是维护用户空间 ABI/API，或者更新用于强制使用这些术语的现有（截至 2020年）硬件或协议规范的代码。 对于新规范，尽可能将术语的规范用法转换为内核编码标准。
5) typedef

请不要使用vps_t之类的东西。 对结构体和指针使用typedef是错误的。 当你看到vps_t a;出现在代码中，是什么意思？ 相反，如果这样
struct virtual_container *a;许多人认为有助于提高可读性。 不是这样的。它们仅在下列情况下有用：
typedef通常，指针或结构体中的元素可以合理被访问到，那么就不应该是typedef。6) 函数

函数应该简短而漂亮，并且只完成一件事。 它们应该一屏或两屏显示完（众所周知，ISO/ANSI屏幕大小为80x24），并且可以做一件事并且做好。
函数的最大长度与该函数的复杂度和缩进级数成反比。 因此，如果你有一个理论上很简单的函数，只是一个很长（但很简单）的 case语句，那么需要在每个case语句做很多小事情，这样的函数可以很长。
但是，如果功能很复杂，并且怀疑天分不是很高的一年级高中生甚至可能根本不了解该函数的功能，则应该更加严格地遵守长度限制。 使用具有描述性名称的辅助函数（如果你认为它们的性能至关重要，则可以让编译器内联它们，效果比写一个复杂的函数要好）。
函数的另一种衡量标准是局部变量的个数。 它们不应超过 5-10 个，否则函数就有问题了。 重新考虑一下函数的实现，并将其拆分为更小的函数。 人脑通常可以轻松地跟踪约7种不同的事物，如果更多的话就会变得混乱。 即使你再聪明，你也可能会记不清两个星期前做过的事。
在源文件中，用一个空行分隔函数。 如果导出了该函数，则该函数的EXPORT宏应紧跟在结束大括号的下一行。 例如：int system_is_up(void){ return system_state == SYSTEM_RUNNING;}EXPORT_SYMBOL(system_is_up);在函数原型中，最好包含参数名称和其数据类型。 尽管 C 语言没要求必须这样做，但在 Linux 中提倡这样做，因为这样可以很简单的给读者提供更多的有价值的信息。
请勿将extern关键字与函数原型一起使用，因为这会使行更长，并且并非绝对必要。goto语句的等价物经常以无条件跳转指令的形式被编译器使用。gotogoto语句会派上用场。 如果不需要清理，则直接返回。选择标签名称，要能说明goto的功能或goto存在的原因。 如果goto中转到释放buffer的地方，则标签名字为out_free_buffer:err1:err2:之类的 GW-BASIC 名称，因为如果你添加或删除出口路径，则必须重新编号它们，并且它们无论如何都会使正确性难以验证。
陈孝松注：GW-BASIC 是 BASIC 的一个方言版本，这个版本的 BASIC 最早是微软在 1984 年为康柏（2002 年康柏公司被惠普公司收购）开发的。
使用int fun(int a){ int result = 0; char *buffer; buffer = kmalloc(SIZE, GFP_KERNEL); if (!buffer) return -ENOMEM; if (condition1) { while (loop1) { ... } result = 1; goto out_free_buffer; } ...out_free_buffer: kfree(buffer); return result;}要注意的一种常见错误是此代码中的错误是在某些出口路径上fooNULL。 通常，此问题的解决方法是将其分为两个错误标签err_free_bar:理想情况下，你应该模拟错误以测试所有出口路径。
8) 注释

注释是好的，但也有过度注释的危险。 永远不要尝试在注释中解释代码是如何工作的：更好 的做法是让别人一看代码就可以明白，解释写的很差的代码是浪费时间。
通常，你希望你的注释告诉别人你的代码做了什么，而不是怎么做的。 另外，请尽量避免在函数体内添加注释：如果函数太复杂以至于需要单独注释其中的某些部分，则可能应该回到第6章看一看。 你可以加一些小注释，注明或警告某些特别聪明（或糟糕）的做法，但不要加太多。 你应该将注释放在函数的头部，告诉人们它做了什么，以及这么做的原因。
在注释内核 API 函数时，请使用 kernel-doc 格式。详细信息请参考：Documentation/doc-guide/ 和scripts/kernel-doc。/** 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.*//** 这是Linux内核源代码中多行注释的首选风格。* 请始终使用这种风格。** 说明：左侧是星号列，开始和结束的行几乎是空白的。*/对于net/和drivers/net/中的文件，长（多行）注释的首选风格略有不同。/* The preferred comment style for files in net/ and drivers/net* looks like this.** It is nearly the same as the generally preferred comment style,* but there is no initial almost-blank line.*//* net/和drivers/net/中的文件的首选注释风格如下所示。 ** 它几乎与一般的首选注释风格相同，但是开始的行不是几乎空白的。*/注释数据（无论是基本类型还是衍生类型）也很重要。 为此，每行仅使用一个数据声明（不要使用逗号来一次声明多个数据）。 这为你留出了对每个数据写一段小注释的空间，以解释其用途。
这没什么，我们都是这样。 长期的 Unix 用户帮手可能已经告诉你 GNUemacs会自动为你格式化 C 源代码，并且你已经注意到，确实可以这样做，但是它使用的默认值并不理想（实际上 ，它们比随机输入更糟糕-无限数量的猴子在 GNUemacs因此，你要么放弃 GNU，要么改变它让它使用更合理的设定。 为此，你可以将以下内容粘贴到.emacs文件中：(defun c-lineup-arglist-tabs-only (ignored)"Line up argument lists by tabs, not spaces"(let* ((anchor (c-langelem-pos c-syntactic-element))(column (c-langelem-2nd-pos c-syntactic-element))(offset (- (1+ column) anchor))(steps (floor offset c-basic-offset)))(* (max steps 1)c-basic-offset)))(dir-locals-set-class-variables'linux-kernel'((c-mode . ((c-basic-offset . 8)(c-label-minimum-indentation . 0)(c-offsets-alist . ((arglist-close . c-lineup-arglist-tabs-only)(arglist-cont-nonempty . (c-lineup-gcc-asm-reg c-lineup-arglist-tabs-only))(arglist-intro . +)(brace-list-intro . +)(c . c-lineup-C-comments)(case-label . 0)(comment-intro . c-lineup-comment)(cpp-define-intro . +)(cpp-macro . -1000)(cpp-macro-cont . +)(defun-block-intro . +)(else-clause . 0)(func-decl-cont . +)(inclass . +)(inher-cont . c-lineup-multi-inher)(knr-argdecl-intro . 0)(label . -1000)(statement . 0)(statement-block-intro . +)(statement-case-intro . +)(statement-cont . +)(substatement . +)))(indent-tabs-mode . t)(show-trailing-whitespace . t)))))(dir-locals-set-directory-class(expand-file-name "~/src/linux-trees")'linux-kernel)这将使 emacs更好地配合~/src/linux-trees下 C 文件的内核编码风格。
但是，即使你无法使 emacs进行合理的格式化，也并不意味着你失去了一切：还可以用indent。
现在，再次，GNUindent具有与 GNUemacs有问题的设定，所以你需要给它一些命令选项。 但是，这并不算太糟，因为即使 GNUindent的作者也认同 K＆R 的权威（GNU 的人并不是坏人，他们在此问题上受到严重误导），所以你只需给indent指定选项-kr -i8（ 代表 “K&R, 8 character indents”），或使用scripts/Lindent（以最时髦的方式缩进）。indent有很多选项，尤其是重新格式化注释时，你可能需要看一下手册页。 但是请记住：indent请注意，你还可以使用clang-format工具来帮助你遵循这些规则，快速自动地重新格式化部分代码，并查看完整文件，以发现编码风格错误，错别字和可能的改进。 它对于排序#includes，对齐变量/宏，重排文本和其他类似任务也很方便。更多详细信息，请参见文件Documentation/process/clang-format.rst 对于整个源代码树中的所有 Kconfig* 配置文件，缩进有些不同。 紧挨 在config定义下面的行缩进一个制表符，帮助信息则再多缩 2 个空格。 例子：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.严重危险的功能（例如对某些文件系统的写支持）应在其提示字符串中突出显示这一点：
config ADFS_FS_RW bool "ADFS write support (DANGEROUS)" depends on ADFS_FS ...有关配置文件的完整文档，请参阅文件Documentation/kbuild/kconfig-language.rst。11) 数据结构

在创建和销毁它们的单线程环境之外具有可见性的数据结构应始终具有引用计数。 在内核中，不存在垃圾回收（并且在内核之外，垃圾回收是缓慢且效率低下的），这意味着你绝对必须引用计数所有使用情况。
引用计数意味着你可以避免上锁，并允许多个用户并行访问数据结构 - 不必担心这个数据结构仅仅因为暂时不被使用就消失了，因为休眠一段时间或做了其他事情。
请注意，上锁不能代替引用计数。 上锁用于保持数据结构的一致性，而引用计数是一种内存管理技术。 通常两者都是必需的，并且不要相互混淆。
的用户时，许多数据结构的确可以具有两级的引用计数。 子类计数器对子类用户的数量进行计数，并且当子类计数器变为零时，全局计数器减一。这种多级引用计数（multi-level-reference-counting）的示例可以在内存管理（：mm_users和mm_count）以及文件系统代码（s_count和s_active）中找到。请记住：如果另一个线程可以找到你的数据结构，并且你没有对其的引用计数，则几乎可以肯定有一个bug。
12) 宏、枚举和 RTL

定义常量的宏名称和枚举中的标签均使用大写字母。
#define CONSTANT 0x12345定义多个相关常量时，最好使用枚举。
宏的名字请用大写字母，但是类似于函数的宏可以用小写字母命名。
通常，内联函数比类似于函数的宏更可取。
具有多个语句的宏应包含在do-while语句块中：#define macrofun(a, b, c) \ do { \ if (a == 5) \ do_this(b, c); \ } while (0)使用宏时应避免的事情：
内核开发者应该是受过良好教育的。 请注意内核消息的拼写，以给人留下深刻的印象。 不要使用不正确的收缩，例如； 而要使用do not或don't。 使消息简单、明了、无歧义。内核消息不必以句点（即点号）终止。
括号中的数字（%d）没有任何价值，应避免使用。中有许多驱动模型诊断宏driver model diagnostic macros，你应使用这些宏来确保消息与正确的设备和驱动程序匹配，并以正确的级别进行标记：dev_err、dev_warn、dev_info等。 对于与特定设备无关的消息， 定义了pr_notice、pr_info、pr_warnpr_err写出好的调试消息可以是一个很大的挑战。 一旦有了它们，它们将为远程故障排除提供巨大帮助。 但是，调试消息的打印方式与打印其他非调试消息的方式不同。 虽然其他pr_XXX函数无条件打印，但pr_debug不会； 除非定义了DEBUG或设置了CONFIG_DYNAMIC_DEBUG，否则编译器会忽略它。dev_dbg也是如此，并且相关的约定使用VERBOSE_DEBUG将dev_vdbg消息添加到已由DEBUG许多子系统具有 Kconfig 调试选项，可以在相应的 Makefile 中打开-DDEBUG。 在其他情况下，特定文件定义了#define DEBUG。 并且当应无条件打印调试消息时（例如，如果它已经在与调试相关的#ifdef中），可以使用内核提供以下一般用途的内存分配函数：kmalloc、kzalloc、kmalloc_array、kcalloc、vmalloc、vzalloc。 请参阅 API 文档以获取有关它们的更多信息：Documentation/core-api/memory-allocation.rst 。另外一种传递方式中，sizeof的操作数是结构体的名字，这样会降低可读性，并且可能会引 入 bug。有可能指针变量类型被改变时，而对应的传递给内存分配函数的sizeof陈孝松注：有可能出现以下情况：
int *p; /* 最开始是 char *p, 后来修改成 int *p */ p = kmalloc(sizeof(char), ...); 强制转换void指针的返回值是多余的。 C 语言保证了从void指针到任何其他指针类型的转换是没问题的。分配数组的首选形式如下：
p = kmalloc_array(n, sizeof(...), ...);分配初始化为零的数组的首选形式如下：
p = kcalloc(n, sizeof(...), ...);两种形式都检查分配大小 n * sizeof(...)上的溢出，如果发生，则返回NULL。
这些通用的分配函数在不带 __GFP_NOWARN的情况下使用时，都会在失败时发出堆栈转储，因此在返回NULL时不会有其他失败消息。
15) 内联弊病

有一个常见的误解是内联函数（inline）是 gcc 提供的可以让代码运行更快的一个选项。 虽然可以适当使用内联函数（例如，作为替换宏的一种方法，请参见第 12 章），不过很多情况下不是这样。 大量使用inline关键字会导致内核变大，这会降低整个系统的速度，这是因为 CPU 的 icache 占用量更大，而且会导致 pagecache 的可用内存减少。 考虑一下：pagecache 未命中会导致磁盘查找，这很容易花费 5 毫秒。5 毫秒的时间内 CPU 能执行很多指令。一个基本的原则是不要对其中包含多于 3 行代码的函数进行内联。该规则的例外情况是参数已知为编译时常量，并且由于该常量，你确定编译器将能够在编译时优化大部分函数。 一个很好的示例就是kmalloc人们经常主张说，将inline添加到static且仅使用一次的函数，不会有任何损失，因为没有什么好权衡的。 尽管从技术上讲这是正确的，但是gcc能够在没有帮助的情况下自动内联这个函数，而且其他用户可能会要求移除inline，由此而来的争论会抵消inline函数可以返回许多不同类型的值，最常见的值之一是指示函数成功还是失败的值。 这样的值可以表示为错误代码整数（-Exxx = failure，0 = success）或是否成功的布尔值（0 = failure， non-zero = success）。
混合使用这两种表达方式是难于发现的 bug 的来源。 如果 C 语言能严格区分整数和布尔值，则编译器会为我们找到这些错误……但是 C 语言不区分。 为防止此类错误，请始终遵循以下约定：
如果函数的名字是一个动作或者强制性的命令，则该函数应返回错误代码整数。 如果是一个判断，则函数应返回表示是否“成功”的布尔值。
例如，add workadd_work0-EBUSY。 同样，PCI device present是一个判断，如果成功找到匹配的设备，pci_dev_present函数将返回所有 EXPORT函数必须遵守此约定，所有公共函数也应遵守此约定。 私有（static）函数不是必需的，但建议这样做。
返回值是计算的实际结果而不是指示计算是否成功的函数不受此规则的约束。 通常，它们通过返回超出范围的结果来指示失败。 典型的例子是返回指针的函数。 他们使用 NULL或ERR_PTR机制来报告错误。
17) 使用布尔

Linux 内核的布尔类型是 C99_Bool类型的别名。 布尔值只能是01，并且隐式或显式转换为布尔值，会自动将值转换为truefalse使用布尔值时，应使用true和false在适当的时候使用可以使用布尔返回类型的函数和堆栈变量。 鼓励使用布尔值来提高可读性，并且在存储布尔值时通常比使用整型类型更好。
如果缓存行的布局cache line layout或值的大小size of the value很重要，请不要使用布尔，因为其大小和对齐方式会根据编译的体系结构而变化。 针对对齐和大小进行了优化的结构不应使用布尔值。
如果结构体具有许多true/false，请考虑将它们合并到具有 1 个位成员的位域中，或使用适当的固定宽度类型（例如u8）。类似地，对于函数参数，可以将许多true/false值合并为单个按位的flags参数，并且如果调用位置具有裸露的true/false常量，则flags通常是更具可读性的替代方法。否则，在结构体和参数中限制使用布尔可以提高可读性。
18) 不要重新发明内核宏

头文件include/linux/kernel.h包含许多你应该使用的宏，而不要自己写一些它们的变种。 例如，如果你需要计算数组的长度，请利用宏：#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))同样，如果需要计算某些结构成员的大小，请使用：
#define sizeof_field(t, f) (sizeof(((t*)0)->f))minmax宏会进行严格的类型检查。 你可以自己看看那个头文件里还定义了什么你可以拿来用的宏，如果有定义的话，你就不应在你的代码里自己重新定义。一些编辑器可以解释用特殊标记表示的嵌入在源文件中的配置信息。 例如，emacs或者这样的：
/*Local Variables:compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c"End:*/不要在源文件中包含任何这些。 人们具有自己的个人编辑器配置，并且你的源文件不应覆盖它们。 这包括用于缩进和模式配置的标记。 人们可以使用他们自己定制的模式，或者使用其他可以产生正确的缩进的巧妙方法。
20) 内联汇编

在特定于体系结构的代码中，你可能需要使用内联汇编与 CPU 或平台功能交互。 必要时不要犹豫。 但是，当 C 可以完成这项工作时，请不要随意使用内联汇编。 你可以并且应该在可能的情况下用 C 操作硬件。
考虑编写简单的辅助函数，这些函数包装内联汇编的常用位，而不是重复编写稍有变化的函数。 请记住，内联汇编可以使用 C 参数。
大型的，非平凡（大量的）的汇编函数应放在 .S文件中，并在 C 头文件中定义相应的 C 原型。 汇编函数的 C 原型应使用asmlinkage。
你可能需要将 asm语句标记为volatile，以防止 GCC 在未发现任何副作用的情况下将其删除。 但是，你不一定总是需要这样做，因为这样做可能会限制优化。
当编写包含多个指令的单个内联汇编语句时，将每条指令放在单独的行中，放在单独的带引号的字符串中，用21) 条件编译

尽可能不要在.c文件中使用预处理条件（#if、#ifdef）； 这样做会使代码更难阅读，逻辑也更难遵循。 而是在头文件中使用此类条件，以定义在那些.c文件中使用的函数，在#else情况下提供 no-op（无操作） stub 版本，然后从.c文件中无条件调用这些函数。 编译器将避免为 stub calls 生成任何代码，从而产生相同的结果，但是逻辑将易于遵循。最好编译出整个函数，而不是编译部分函数或表达式的一部分。 不要将ifdef放入表达式中，而是将部分或全部表达式封装成函数，然后调用该函数。如果你具有在特定配置中可能未使用的函数或变量，并且编译器会警告其定义未使用，请将该定义标记为__maybe_unused，而不是将其包装在预处理条件中。 （但是，如果函数或变量始终不使用，请将其删除。）在代码内，在可能的情况下，使用IS_ENABLED编译器将不断折叠条件，并像#ifdef一样包含或排除代码块，因此这不会增加任何运行时开销。 但是，这种方法仍然允许C编译器查看块中的代码，并检查其是否正确（语法，类型，符号引用等）。 因此，如果块内的代码引用了如果不满足条件将不存在的符号，则仍然必须使用#ifdef在任何重要的#if或#ifdef代码块的末尾（多行），在同一行的#endif后面放置注释，并注明所使用的条件表达式。 例如：#ifdef CONFIG_SOMETHING...#endif /* CONFIG_SOMETHING */附录 I) 参考

The 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 http://www.gnu.org/manual/
WG14 is the international standardization working group for the programming language C, URL: http://www.open-std.org/JTC1/SC22/WG14/
Kernel :ref:



欢迎光临 嵌入式开发交流网论坛 (http://www.dianzixuexi.com/bbs/) Powered by Discuz! X3.2