linux内核编码风格

1、linux内核目录/kernel/Documentation/CodingStyle是linus写的关于linux内核编码风格的文章；
2、中英文对照：
This is a short document describing the preferred coding style for the linux kernel. Coding style is very personal, and I won’t force my views on anybody, but this is what goes for anything that I have to be able to maintain, and I’d prefer it for most other things too. Please at least consider the points made here.
本文简短的描述了linux内核首选编码风格。编码风格因人而异，我不对任何人强加自己的观点。但是，这件事情我必须坚持，其它无所谓。请至少参考以下观点。
First off, I’d suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it’s a great symbolic gesture.
首先，我建议打印一份GUN编码编码标准，然后不要读。烧掉它是个好的象征动作。
Anyway, here goes:
行了，接下来：
Chapter 1: Indentation
第一章：缩进
Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.
制表符是8字符长度，因此缩进也是8字符长度。但是有些异类要缩进四个字符深，这就跟要把PI值定义为3一样。
Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you’ve been looking at your screen for 20 straight hours, you’ll find it a lot easier to see how the indentation works if you have large indentations.
论据：缩进的意义在于可以清晰的定义一段代码的开始和结束。尤其当你要持续盯着屏幕20个小时，你就更容易发现大的缩进的意义。
Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program.
现在有人要说8字符的缩进会让代码移到右边去了，使得很难在80字符宽的显示器上阅读。但问题是假如你要缩进三个级别，那你就完蛋了，你要好好改下你的程序了。
In short, 8-char indents make things easier to read, and have the added benefit of warning you when you’re nesting your functions too deep. Heed that warning.
简单来说，8字符的缩进会让代码阅读更清晰，并且还有一个好处就是提醒你的代码嵌套的太深了。警钟长鸣。
The preferred way to ease multiple indentation levels in a switch statement is to align the “switch” and its subordinate “case” labels in the same column instead of “double-indenting” the “case” labels. E.g.:
最好的简化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;
	}

Don’t put multiple statements on a single line unless you have something to hide:
不要把多条语句放在一行除非你要藏什么

if (condition) do_this;
	  do_something_everytime;

Don’t put multiple assignments on a single line either. Kernel coding style is super simple. Avoid tricky expressions.
也不要把多个变量放一行。内核代码风格极简。避免啰嗦的表达
Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken.
除了注释，文档包括Kconfig，都不要用空格来缩进，以上例子都是故意搞破坏的
Get a decent editor and don’t leave whitespace at the end of lines.
找个好的编辑器，不要在行位留空格
Chapter 2: Breaking long lines and strings
第二章：拆掉很长的行和字符串
Coding style is all about readability and maintainability using commonly
available tools.
编码风格在于使用常见的工具时的可阅读性和可维护性
The limit on the length of lines is 80 columns and this is a strongly
preferred limit.
行长的限制是80，最好不过了
Statements longer than 80 columns will be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information. Descendants are always substantially shorter than the parent and are placed substantially to the right. The same applies to function headers with a long argument list. However, never break user-visible strings such as printk messages, because that breaks the ability to grep for them.

---

语句超过80列宽就要被分为块，除非80列宽显著提高了可阅读性同时不会隐藏任何信息。后面的语句要比前面的要短，而且通常都会靠右放。同样适用于有长参数列表的函数头。但是，千万不要拆掉用户可见的字符串比如打印信息，因为grep起来会很难。
Chapter 3: Placing Braces and Spaces
花括号和空格的打法
The other issue that always comes up in C styling is the placement of
braces. Unlike the indent size, there are few technical reasons to
choose one placement strategy over the other, but the preferred way, as
shown to us by the prophets Kernighan and Ritchie, is to put the opening
brace last on the line, and put the closing brace first, thusly: