本文探讨编程中的一个术语：“可读性”。
首先我们来谈谈它的含义：
“可读性”是描述在其他开发人员没有进行太多联想或猜测的情况下就能理解代码的含义。为了让其他的开发者对你的代码“可读”，你需要谨慎选择每个变量命名甚至是参数命名。
但是有些东西是普遍存在而且也是受到人为因素的限制的。例如，很少会有开发者去追踪命名不定的变量。
启发：变量，类，方法和其他引用是否有明确的名称？
或者从开发者本身的角度看，这些开发人员是否熟悉正在接管的项目代码？他们作为开发人员有多经验？他们是否有特定的背景使得代码对他们有或多或少的可读性？
但是我们通常会遇到这样的应用场景：你并不知道其他开发者是谁？这在开源项目中最为普遍。
所以这就是我们在编程中制定标准，模式和最佳实践的原因。例如，JavaScript 代码倾向于使用 camelCase （驼峰命名），因此使用 camelCase 编写代码可以提供流畅的感觉（这就可以起到可读性的作用）。了解一门语言通常使用的常见模式和风格非常重要。
补充：你所在的团队可能会制定一些自己的编程规定; 这个时候请你遵循它。
以下是可以遵循的一些简单而实用的方法：
尽量使用描述性变量名称。 更长的变量一般更具有可读性。
使用空格！ 代码编译器的存在意味着空格对于代码执行来说是无关紧要的的，但是空格对于人来说，确实很重要！所以要利用好这一个优势。
在抽象和实用性之间找到一个平衡点。 比如最简单的任务不需要 10 层重定向; 而是要从最简单的方法开始，在重构过程中进行抽象。
“让代码跑起来，然后跑得对，最后跑得快。” 注意遵守这个顺序。 这将极大地帮助你提高代码的可读性，因为你首先从理解开始，然后转向性能。 这就预先建立了你的模式和语义，你更有可能以这种方式保持良好的语义化。
了解你的受众。 如果你的受众不习惯内联的 lambda 计算，请不要使用它。 即使您认为这是解决问题的“最佳途径”，但还有其他同样可行的方法。
遵循完善的重构和面向对象的模式。讲真， 这些概念都是前辈尝试和测试过的，你可以先不用怀疑太多，先准守它。
但是！也不要盲目遵守规则。 不定期地花些时间去重新审视代码：有没有什么东西很奇怪？ 这混淆了什么么？ 这样写是不是更好？
可读性高的代码不总是易于维护的，反之亦然。 可维护的代码通常是遵循良好的实践和原则建立起来的。
测试对代码库维护非常重要！拥有良好的测试覆盖率使您不必将所有代码记在您的脑海中。 （注意：测试不会一起消除错误，但是测试对你的帮助非常大。）
总而言之，编程是一个人为的过程。 在编写代码时遵循下面的建议:
更简单通常会更好 —海明威。