代码简单：独立于语言的观点

简单就是美丽是编程中的金句。尽管效率和性能是主要因素，但在许多用例中，简单性和维护成本才是胜过它们的因素。这些成为选择编程语言，探索语言功能甚至决定组织内标准编码实践时的决定性因素。对于特定的编程语言是否可以使编写更简单和可维护的代码变得更容易，通常存在争议。随着代码库的增长和使用代码库的人员的数量开始增加，项目通常会从一种更高效，更高效的语言转移到其他语言。

许多这样的决定对于某些团队来说确实非常有效，而且其中许多未能改变地面现实。让我们探讨一下，什么使代码简单，以及我们在这方面可以做什么。

是什么使代码简单

具有讽刺意味的是，编写简单的代码既不容易也不简单，有时简化逻辑或一段代码实际上可能非常复杂。

一些简单易写的标志：

易于阅读和理解

通常，代码只编写一次，并在一段时间内读取数百次。因此，重要的是应易于阅读和理解。

一些简单的技巧可以帮助您：

避免双重否定 ：不要说if（！not_present）使用if（present）。
避免误导缩写 ：一旦我们从事与销售点相关的项目。由于时间更长，我们将其缩短为POS。为了检查特定对象是否属于POS，我们添加了一个名为isPOS的方法，该方法将获取一个对象并相应地返回true或false。该对象还具有正数或负数的概念（它也与数量有关）。最近加入团队的新开发人员必须添加一些功能，并且需要检查该对象是否具有正数，他使用了isPOS方法（假设其为isPositive的快捷方式）并继续。由于大部分金额被认为是负数，并且也很少有对象与POS相关，因此他的大部分测试均正确通过。也没有人在代码审查中发现这一点，并且在代码投入生产后的整个周期中都非常晚。
遵循自然的命名约定 ：如果变量w用于ResponseWriter，r通常表示ResponseReader，请勿将其用于Request。
在if块中避免出现多个复杂的条件：在处理旧版代码时，仅添加一个条件并完成功能是很诱人的。尽管大多数情况下它运行良好，但这些额外条件仍在不断改变业务意图，并且在几次迭代之后，业务逻辑变得完全无法管理。因此，无论何时添加新条件，确保它在较旧的上下文中仍然有用，这一点很重要，如果没有，那么稍微重构可能是一个更好的选择。
避免魔术逻辑 ：应避免以牺牲可读性为代价的效率。例如X << 3（将数字X左移3）而不是X * 8（将X乘以8）可能会更快，但可读性可能不同。除非意图相同，否则避免此类内容通常有助于提高可读性。

易于理解代码/实现上下文

人们经常四处走动，新人们不得不查看代码，而他们所面对的问题和所解决问题的背景可能并不相同。因此，从代码中获取上下文越容易，新人们就会越有生产力。几件事可以帮助您：

方法之间的状态和依赖性更少 ：依赖状态的其他方法或需要按特定顺序调用的方法使阅读和修改变得更加困难。我们不仅必须阅读和理解当前方法，还需要了解通话顺序。通常，这会导致调用当前状态未正确更新的方法，从而导致问题。 不要在类中使用成员变量来存储临时状态，以避免在私有方法中使用额外的参数 。
特定的输入和输出 ：很多时候，将较大的通用数据结构传递给方法比较容易，如果方法需要更多的输入，则可以方便以后进行修改。但是，这通常也导致方法的可重用性降低。另外，通过在调用方读取代码，也很难猜测另一端可能发生的情况。这迫使我们阅读更多代码以理解逻辑。同样，返回较大的结构并仅填充很少的字段，迫使我们阅读更多代码以了解响应后可以使用结构的哪一部分，这通常会导致访问未填充的数据并使代码变脆。最好只传递所需的输入并返回特定的输出。
重定向少 ：进行太多重定向会迫使我们阅读更大的代码库。优先使用较小的重定向。例如下面的代码（有点夸张），

有很多东西很可能不会改变。这种不必要的抽象使获取上下文变得更加困难。

因此，用一种简单的方法替换所有这些方法可能是值得的

易于获得意图和问题背景

当需要修改现有代码时，问题的上下文和意图将比实现步骤提供更多帮助。因此，有意义的抽象很重要。

有意义的抽象

我们可以编写一个非常具体的代码，该代码在上下文中可以很好地工作，但可能会隐藏意图。

例如，假设我们正在建立一个电子商务站点，并且结帐完成后，我们需要发送一封电子邮件以指示结帐已经完成，如果有错误，我们可能需要发送另一封电子邮件。假设有2个步骤才能将结帐视为完成，并且我们可以设想第1步后系统出错的情况。还假设我们将每个步骤的成功记录为一行（在内存或实际DB中）记录在DB中。

这是一个示例实现。

尽管对于给定的条件这可能会很好地工作，但这并不能正确告知目标，而将重点更多地放在当前的假设上。如果稍后我们添加一个新步骤，则此代码将中断。为新人修改此代码将非常困难，因为缺少特定步骤的意图。

在这些情况下，使用更多代码但有正确意图的实现可能会更好

简单即美

最后，重要的是传达正确的上下文和含义。易于阅读和浏览但不能揭示正确意图的代码可能不会被视为简单代码。尽管语言及其功能可能起着重要的作用，但是如果我们照顾好这些基本的东西，则无论我们使用哪种语言，哪种范例或某种语言的功能，我们的代码都有可能仍然很漂亮。

From: https://hackernoon.com/code-simplicity-a-language-independent-perspective-756cf031c913