Linux内核码风格(编程代码风格推荐).docVIP

这是翻译版本，英文原版是linux源码Documentation文件夹下的CodingStyle一个良好风格的程序看起来直观、美观，便于阅读，还能有助于对程序的理解，特别在代码量比较大情况下更显现编码素质的重要性。相反没有良好的风格的代码读起来难看、晦涩，甚至有时候一个括号没对齐就能造成对程序的曲解或者不理解。我曾经就遇见过这样的情况，花费了很多不必要的时间在程序的上下文对照上，还debug了半天没理解的程序。后来直接用indent -kr -i8给他转换格式来看了。特此转过来一个关于代码风格的帖子分享一下～Linux内核编码风格 这是一份简短的，描述linux内核首选编码风格的文档。编码风格是很个人化的东西，而且我也不愿意把我的观点强加给任何人，不过这里所讲述的是我必须要维护的代码所遵守的风格，并且我也希望绝大多数其他代码也能遵守这个风格。所以请至少考虑一下本文所述的观点。首先，我建议你打印一份GNU的编码规范，然后不要读它。烧掉它，这是一个很高调的具有象征意义的姿态。Anyway, here goes: 第一章：缩进制表符是8个字符，所以缩进也是8个字符。有些异端运动试图将缩进变为4（乃至2）个字符深，这跟尝试着将圆周率PI的值定义为3没什么两样。理由：缩进的全部意义就在于清楚的定义一个控制块起止于何处。尤其是当你盯着你的屏幕连续看了20小时之后，你将会发现大一点的缩进将会使你更容易分辨缩进。现在，有些人会抱怨8个字符的缩进会使代码向右边移动的太远，在80个字符的终端屏幕上就很难读这样的代码。这个问题的答案是，如果你需要3级以上的缩进，不管缩进深度如何你的代码已经有问题了，应该修正你的程序。简而言之，8个字符的缩进可以让代码更容易阅读，还有一个好处是当你的函数嵌套太深的时候可以向你提出告警。请留意这个警告。在switch语句中消除多级缩进的首选的方式是让“switch”和从属于它的“case”标签对齐于同一列，而不要“两次缩进”“case”标签。比如： switch suffix case G: case g: mem 30; break; case M: case m: mem 20; break; case K: case k: mem 10; /* fall through */ default: break; 不要把多个语句放在一行里，除非你有什么东西要隐藏： if condition do_this; do_something_everytime;也不要在一行里放多个赋值语句。内核编码风格超级简单。就是请避免使用怪异的表达式。除了注释、文档和Kconfig之外，不要使用空格来缩进，前面的例子是例外，是有意为之。选用一个好的编辑器，不要在行尾留空格。 第二章：把长的行和字符串打散编码风格的意义就在于使用平常使用的工具来维持代码的可读性和可维护性。每一行的长度的限制是80列，我们强烈建议您遵守这个惯例。长于80列的语句要打散成有意义的片段。每个片段要明显短于原来的语句，而且放置的位置也明显的靠右。同样的规则也适用于有很长参数列表的函数头。长字符串也要打散成较短的字符串。唯一的例外是超过80列可以大幅度提高可读性并且不会隐藏信息的情况。void fun int a, int b, int c if condition printk KERN_WARNING Warning this is a long printk with 3 parameters a: %u b: %u c: %u \n, a, b, c ; else next_statement; 第三章：大括号和空格的放置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）KR是 正确的， 并且（b