在编写代码时，通常会采取什么措施来确保其可读性？

对于这个问题，Linux 的发起者，Linus Torvalds 是专业的。如果你从业时间久一点，肯定或多或少听说过他的 代码3大原则 。这个可以说是家喻户晓，如果没听说过，可以简单看一下。

他有个名言呐！代码是写给人看的，只是顺便给机器运行。(*≧∪≦) 笑死我了！

然后他对别人给他提交的代码，很是看重，很是严谨。他的原则浸透了 Linux 内核代码风格 。主要思想就是下面这些。我觉得还是很有参考价值的。

首先是缩进。

linus 说，缩进就该是 8 个字符的缩进！

添加图片注释，不超过 140 字（可选）

他说的理由是，当你连续 20 个小时，阅读复杂代码，缩进更多会更轻松。

当然，我们直接就能怼：代码缩进搞那么夸张，会很容易让代码跑到屏幕右边，太难看了太不易读了！

linus 说啊：没错！因为缩进实际上是在警告我们，不要写很多嵌套。别让代码跑出屏幕右边框。

我认为，是有点意思。不过我一直用的 4 个，因为 8 缩进..... 还是不习惯。github 里面很多都是 8 缩进的，因为没遵守 linus 的这个原则，看着很难受。但我可以肯定的是， 2 缩进是绝对不行的。

第二个是，一个原则: 函数的最大长度，与该函数的复杂程度与缩进级别成反比！

用人话说，很简单：

随着函数的复杂度 和 缩进的增加，该函数的所被允许的最大长度，应该减小。更多的缩进，意味着更大的复杂度！

其实，就是如果一个函数太长，说明它干了太多的活，或者逻辑太复杂。

一个函数只应该做一件事。

是的，这个很重要。我写代码，就是一个屏幕里，全部都能看见。尤其是横向的滚动条，从来不会去用。

看来， 8 缩进还是很有必要的，越极端的环境，越能养蛊！函数不能太宽，太长，能一眼看完就一眼看完！函数做一件事，并把它做好。

第三个 很匪夷所思：

永远不要在代码中解释，你的代码是如何工作的！

其实不要误会，linus 不是说不要写注释，而是少写注释，不能解释工作原理，而是介绍干了啥，为什么。比如：

一个尽显 C 代码美学的艺术品

他说，像这种代码，很巧妙，但是很难阅读。

注解：这代码实现的功能是，把src（源字符串）的内容，一个字符接一个字符地复制到dest（目标字符串）中，直到复制完字符串的结束符\0为止。

而 linus 认为，这会让所有阅读到这里的开发人员，浪费时间去阅读。还不如不炫技，直接重构，重写成容易阅读理解的样子：

清晰明了

这个时候，如果你高兴，你可以简单写个注释，说这块代码做了什么。这是 linus 允许的。

但是千万不要在 代码 里解释代码的工作原理。但允许简单注释，这块是干啥用的。

或者说可以解释为什么这么做，比如某个地方，我们必须在这里等待 10ms，因为旧款硬件响应速度慢。

这3大原则，经过很多年，还是非常著名。总结的很浓缩、全面，只要能牢牢遵守上面的这些思想，你的代码可读性就不会很差。

这是我以前认识的一个大学生写的 (T_T) ：

完全不符合 linus 的原则 哈哈哈，可以当反面教材

最后我再补充一点：不要使用只有自己才看得懂的标识符命名！