什么叫代码的可读性？为什么说Kotlin的可读性比Java高？
不久之前，我看了一篇文章，大意是Kotlin与Java之间的对比，像这种文章，我一般是直接忽略的，但是那天我还是打开了，然后就看到一个非常吃惊的结果。 里面有一段是关于Kotlin与Java之间可读性的对比的文章，作者的结论是：Kotlin并不比Java更具有可读性，所有认为Kotlin 比Java更具有可读性的结论都是“主观性”的。 并且作者举了一个在我看来，不知道该怎么来描述的例子： 这个作者的大意是，上面这段文章，你多读个两三遍，你也会很快的理解它的意思，所以“对于熟练的读者而言，外观很少会成为可读性的障碍。” 我不知道，如果某一天，这个作者突发奇想，决定全部使用大写字母来写代码——所有的类名、方法名、局部变量成员变量名等等全部使用大写，我不知道跟作者合作的同事是不是会欣然的耐心的把作者所有的代码先读它个两三遍，然后再来慢慢的理解它的意思。如果是我，我不会。如果在小红书有个同事非要执意这样写代码，理由是“你多读个两三遍不就好了嘛？”我想我只能把他开除了。 其实，如果一段代码需要你多读个两三遍才能很好的理解，这本身不就说明，这段代码的可读性不高吗？这里的重点是，这里的这一段大写的文字你看个三遍，再看的话，是熟悉了，但是再看别的用大写写的文字片段，你依然要很费劲。所以，这个例子是不能代表大写这种风格的可读性的。在比较两种不同的风格的可读性的时候，你不能用具体的某一个一次性的片段来说明。 另外，这篇文章还暗含了这样一个观点，那就是，代码的可读性，仅仅是指，看到一段代码，能不能理解这段代码的含义。这是一个很多人都会错误的观点。 但是，在真正工作中，代码的可读性，恐怕不至这一个方面。为了考察所谓代码的可读性涉及到哪些方面，我们来假设两个case：1. 你去到一家新公司，接手一个新项目。这个时候，你的需求是，快速了解某个类、某个模块、某个方法做的是什么事情。在这个基础上，整个app、模块的结构是怎么样的。2. 你老板叫你fix一个bug，这个bug是另外一个同事写的，今天这个同事请假了不在。在这个case里面，你需要的是，快速的定位到出问题的代码在什么地方，然后再尽快的了解这个地方的代码做了什么事情，并且保证你的理解是对的。 所以，总结一下，代码的可读性，可以归纳成三点： 1. 理解一段代码的速度 2. 找到你关心的代码的速度 3. 确保正确理解一段代码的难易程序。这跟第一点看似一样，其实还真不一样，下面你会看到。 下面，依次解释一下这三点，以及为什么说，Kotlin的可读性会对Java高。 ### 1. 理解一段代码的速度 如果大家仔细的思考下，你会发现，我们在理解一段代码的时候，大多数情况下，我们是想要了解这段代码做了什么事情，是这段代码的意图（Intention），而不是具体这个事情是怎么做的。比如一个Button被点击了，我们的App做了什么，是做了什么运算，发了网络请求，还是保证了一些数据到数据库。也就是说，大多数情况下，我们关心的是What，而不是How。只有少数情况下，我们会关心“How”，一是出于学习的目的，我们想要了解一个算法是怎么实现的，一个效果是怎么实现的，这个时候，我们会关心“How”。二是当这个“How”出了问题的时候，就是有了Bug，我们要去了解这个 “How”，然后再fix过来。而且，即使是在这些少数情况下，了解“How”的过程，也只不过是了解一个个子“What”的过程。 敏捷开发和TDD先驱、JUnit开发作者和一系列经典编程书籍作者Kent Beck提出了一个著名的“four rules of simple design”，是以下4条：…