曾经看到过这样一句话「别人在阅读代码过程中飙脏话的频率是衡量你代码质量的唯一标准」。
代码的可读性其实不是针对的编译器、解释器，而是对于人来说的。具有良好可读性的代码，应该是能让人快速理解、轻松维护、容易扩展的。
相信大家都有过维护别人代码的经历，如果各有各的风格，而没有遵循一定的规范和约定的话，那真的是挺痛苦的一件事。当然，既然编写代码被称作是一种艺术，那难免会有多样性。所以这里不会有太多「极端」的要求，只是提出一些建议和判断标准。
这里主要从三个方面说明如何提升代码的可读性：
表面层次的改进。 简化逻辑。 重新组织代码。表面层次的改进是指：选择合适的名字、写清晰的注释、将代码整理为更好的格式等等很容易应用的方式。
当我们在代码中给方法、变量等命名的时候，应该遵循「将信息装入名字 」这一原则。
要将信息装入名字就需要我们在命名时选择专业的词，避免空洞、泛泛的词。比如，单字母、tmp、buf 等无意义的词。当然在循环中大家已经习惯了用 i, j 等来表示索引，所以在这里也可以延续习惯。
注释应该是说明代码的意图，而不是简单的复述代码的行为。当我们在写注释时，应当是从更高的思维层次上来说明编写这段代码时的想法，就像是一个作家在阐述自己写作时的想法一样。 比如：
// 对于这些数据，二叉树要比哈希表快得多。千万不要只是写一大段谁都能从代码里看出来的废话。
目前主流的代码规范都推荐代码宽度保持在 80 为宜，这么做当然是有历史原因，但在现在也还是有其实用价值的。因为将代码宽度限制在 80，是在需要打印代码的时候，完美适配 A4 纸的宽度。即使只是将代码贴在个人博客或在线网站上，这也是最适合代码阅读的宽度。当使用大屏显示器编程时，这个宽度也是很适合分屏工作的。
在这里笔者不推荐使用「列对齐」，比如：
var name = "name"; var location = "location"; var phone = "phone"; var url = "url";因为列对齐看起来确实还不错，让代码的阅读更轻松了些，但这样建立和维护对齐的工作量很大，当某一行有了些细微的变动，其他很多行也要跟着动，而且大部分都还只是空白。当然，如果你觉得这样做的工作量还可以接受，也是可以试一试的。
在组织方法的时候，应该遵循一定的逻辑顺序。但具体要遵照什么逻辑顺序，是可以按照自己的想法的，比如，从「重要」到「不重要」、按字母顺序排序等等。但最重要的是要一直坚持已有的风格，不一致的风格比没有风格更让人混乱。
这里也介绍一些好的代码风格：
Google 的代码风格：包含 C++、Object-C、Java、Python、R、Shell、HTML\CSS、JavaScript、AngularJS、Common Lisp 和 Vimscript。 Feross JavaScript 代码规范。每当你看到一个复杂的逻辑、一个巨大的表达式、一大堆变量时，你就应该思考应该怎么优化它们。因为这些都会增加你头脑的压力，要知道每个人的短期记忆都是很有限的。当你不得不思考过多的事情时，很可能在不知不觉中就产生 bug。 这里介绍几个简化逻辑的方法：
拆分复杂表达式。要拆分复杂表达式，可以使用「解释变量」的方法。比如：
if line.split(':')[0].strip() == "root" 这里我们可以加入一个额外的解释变量：
username = line.split(':')[0].strip() if username == "root" ... 德摩根定理。 如果你学过「电子电路」这门课，那你一定对德摩根定理有印象。也就是对于一个布尔表达式，有两种等价写法： (not a) and (not b) and (not c) = not (a or b or c) (not a) or (not b) or (not c) = not (a and b and c) 你可以用德摩根定律来让你的布尔表达式更具有可读性。 尽可能简化变量。对于变量的使用，主要有三个需要注意的地方： 变量越多，越难全部追踪它们的动向。 变量作用域越大，就需要跟踪它们的动向越久。变量改变得越频繁，就越难跟踪其当前值。
重新组织代码俗称「重构」，没有把握时不要轻易使用。这里介绍几个简单常用的方法，进阶的话可以去看《[重构：改善既有代码的设计](https://www.amazon.cn/重构-
