背景
在最近的博客文章中，我展示了如何使用Java的标签来阐明测试的给定，何时何地部分。 我认为这可以导致更具可读性和可理解性的测试。 显然，由于这是一种风格问题，因此并不是所有人都可以接受的观点，这很自然。 我们大家都可以就这样的方法分享不同的意见，这也很好。 当我的博客文章以出色的dzone联合组织时，我注意到人们发表了一些非常奇怪的评论。
他们不仅不喜欢所讨论的方法，而且不喜欢尝试使代码自然阅读的想法。 这些对点可以分为两个不同的组：
- 不喜欢Java代码阅读像英语的开发人员。
- 如果您希望代码像英语一样阅读，那些认为您应该尝试使用Groovy或Scala的开发人员。
我通常不会花时间回复互联网上的任何旧评论，但我认为这是一个足以发表评论的重要话题。 在这篇博客中，我将解释为什么我认为，无论您使用哪种编程语言， 可读代码都是看起来像问题陈述的代码 。
什么是编程？
编程，编码，黑客（无论您想要称呼什么）都是软件工程的子集，它负责实际编写代码。 我们想要产生一个可以解决某种问题的有效应用程序。 当我们开始时，我们不一定知道问题是什么，但是希望我们对问题的理解会不断改善。 因此，我们试图说服摆在我们面前的有机硅块，它确实想为我们解决问题，而不是被转换回一个大的沙坑。
问题在于，人类所理解的与机器所理解的之间存在巨大的鸿沟。 我不是在谈论猫有多可爱-我的意思是概念阻抗不匹配很大。 所有CPU真正要做的就是基本的算术和逻辑运算。 它们可以用来做其他事情，例如绘制人类基因组图，传播民主或驾驶汽车，但实际上我们所显示的只是这些问题的计算部分等同于基本算术和逻辑运算。
更好的方法
在过去的50年中，我们一直在开发编程语言，试图弥合机器功能与我们要解决的问题之间的差距。 最初，这涉及提供更多抽象的面向机器的结构–循环而不只是有条件地分支的能力以及命名代码blob并使用不同的参数对它们进行参数化的能力。
到1980年代的时候，两组互相竞争的传教士试图告诉我们放弃结构化程序，而接受与机器正交的抽象。 面向对象的程序设计的思想是，我们应该构建代码以对真实世界的对象进行建模，而声明性方法（例如函数式程序设计）则专注于告诉计算机要计算什么而不是如何计算它。
尽管关于这些不同方法的优缺点仍存在大量争论，但很明显，每个人都想尝试使问题与机器之间的差距缩小。 差距越小，实际需要编程的次数就越少。 他们写的越简单，他们读的越容易。 如果您要解决的问题是通过使用与问题域相同的词汇来使用自然语言编写的，则可以缩小此差距。 如果您尝试以功能性或面向对象的方式对现实世界中存在的操作进行建模，则会缩小这一差距。
Java是问题吗？
Java是一种发展缓慢的语言，但是具有丰富的开发人员工具和广泛的库支持，因此是一种多范式语言。 无论您是爱还是厌恶，您都一定会错过重点。 Java是一种特殊情况的语言，在这种情况下，您不会选择尝试以类似于问题的方式读取和编写代码，这不是合理的情况。 这不是特例，它只是另一种编程语言。 我已经以某种方式获得了用Java，Scala，C，Haskell，R，Javascript，Python，Ruby，Posix Compliant Shell *甚至是几个定理证明编写代码的报酬。 在所有情况下，您的代码读起来都越接近，就像它解决的问题一样，读写就越容易。 编程语言很重要，但是一些可读性问题是正交的。
既不完美也不正确
我们都是人类。 我们都会犯错。 我们都写难看的代码。 但是，作为一个行业，我们应该寻求尝试并找出改善自我的方法。 我希望我们所有人都能落后的一个原则是，您的代码看起来越像其问题陈述越容易阅读。
感谢Tom Fitzhenry，Martijn Verburg和Daniel Daniel对这篇博客发表的反馈。
* Bash不是一种编程语言，它是一种拥抱和扩展的解释器。