您为什么关心《守则》的简洁性？

最新推荐文章于 2024-09-16 08:47:17 发布

dfsgwe1231

最新推荐文章于 2024-09-16 08:47:17 发布

阅读量92

点赞数

文章标签：移动开发 java

Debby和Walter在同一团队中担任软件工程师。前几天，他们就代码的简洁性进行了精彩的交谈。

TL; DR

更少的代码可以完成这项工作。
减轻了无法消除的无用重复的痛苦。
当您不能使用简洁的代码时（因为您的编程语言在设计上不是简短的），那么您的重复/重复感就会变得麻木。这会影响注意重复的代码和注意人们（以及您！）执行的重复操作，这些操作应该是自动化的。因此变得对复制/重复变得麻木，使程序员变得更糟。
当样板过多时，将很难理解（并在其中找到错误）代码的核心逻辑。它起到噪音和干扰的作用。
当您习惯于滤除样板之类的噪声时，就很难在所述样板上看到错误。
如果您可以在不牺牲编写简便性的情况下优化可读性/可理解性，那么一定要这样做！
简洁可能会被夸大，以至于损害可读性，易理解性和易写性。确保保持适当的健康平衡。

对话本身

黛比：嘿沃尔特！
沃尔特：嗨，黛比！

黛比：那么，为什么你这么在乎简洁的语法呢？
Walter：简洁的语法使我可以编写更少的代码来完成相同的任务。

黛比：我不能反对。顾名思义就是这样。更多的东西？
Walter：简洁的语法减少了无用重复的痛苦。

黛比：为什么无用的重复会让您感到痛苦？
Walter：程序员工作的主要支柱之一是消除/自动执行重复性任务。如果您的工作是减少重复，那么您会发现其他人不会重复。如果看到重复，而工作是消除重复，那么当您注意到重复时，您会感到痛苦。

黛比：如果您的编程语言本身具有很多无用的重复构造，而您却无能为力，您该怎么办？
Walter：如果您的代码本身在语言级别上具有重复性，并且您对此无能为力，那么每次在代码中编写这样的语句时，您可能都会感到痛苦。

黛比：有趣。您是否仅通过忽略重复足够的时间就使自己麻木了那种痛苦？
沃尔特：是的，可以。让我们重新检查在这种情况下会发生什么。鉴于程序员的工作是消除无用的重复。那么，如果他们变得对某种类型的冗余变得麻木了，将会发生什么？

黛比：如果他们变得对单一类型的重复感到麻木，那么这样的程序员也很可能对其他种类的冗余变得麻木。
Walter：考虑到检测到重复是程序员的工作支柱之一，这意味着什么？

戴比（Debby）：如果程序员对更多类型的重复感到麻木，并且如果他们的工作是检测并消除这种重复，那么他们一定已经变得更糟糕。
沃尔特：是的。

黛比：好吧。点了。关于您为什么还要关心简洁语法的更多信息？
沃尔特：简洁的代码在某种程度上更易于阅读和理解。

黛比：为什么简洁的代码更容易阅读和理解？
沃尔特：如果您从代码段中删除所有样板（无用的重复等），那么您还剩下什么？

黛比：什么是阅读和理解必不可少的。
沃尔特：如果我们有很多样板，会发生什么？找到这段代码的重要之处是容易还是困难？

黛比：如果我们有很多样板，那么我们将不得不集中精力寻找隐藏在其中的内容。在某些情况下，这就像在大海捞针中寻找针头一样。
沃尔特：确实是我的意思。

黛比：您是否同意随着时间的流逝习惯相同类型的样板并在阅读代码时自动将其过滤掉？
沃尔特：我当然同意。而且我认为它仍然会引起一些精神负担。此外，如果您有条件过滤样板，并且您要修复的错误隐藏在样板中，那么将很难找到它。

黛比：有趣的一点。有时候，样板被强加给我们程序员，对吗？就像我在Java中为避免无用和明显的样板一样做什么？
沃尔特：当我不得不使用Java时，我通常使用Lombok编译器插件/库来将无用的样板减少到最小。在我可以选择的其他项目上，Kotlin表现很好。如果您想开始使用Kotlin，请阅读本教程。

黛比：谢谢您的链接。我待会再看！无论如何，您是否会同意样板过多的代码有更多的错误可能性？
沃尔特：当然。它可能在重要的部分中存在错误-代码的核心逻辑。它可能会在附带代码的样板中造成缺陷。如果是这样，那么没有样板的片段代码只能在其核心逻辑中存在错误。

Debby：这意味着调试起来会更容易，因为我们的可能性较小。
沃尔特：是的。

黛比：好吧。我们现在在谈论有关阅读和理解代码的话题。但是程序员的工作是编写代码。真的吗？
沃尔特：是的，从技术上讲。

黛比：那么为什么使代码易于阅读和理解至关重要？易于编写代码会更好吗？
沃尔特：很好的问题！在任何程序员编写代码之前，他们总是必须阅读和理解现有代码。唯一的例外是尚未编写任何代码时新代码库的“第零天”。

黛比：那么还有什么比这更重要的：易于阅读或编写代码？
沃尔特：好的。让我们做一个思想实验。假设我们有一段难以阅读和理解的代码。进行更改（在技术上，编写代码）有多容易或困难？

黛比：就像你说的那样，如果程序员必须在编写代码之前先阅读代码，并且如果代码难以理解，那么就很难进行更改（或很难编写代码）。
沃尔特：对！现在，让我们想象一下情况稍有不同。假设我们有一段易于阅读和理解的代码。对更改进行编码将多么容易或困难？

黛比：我不确定。
沃尔特：你为什么不确定？告诉我您在想什么，您在做什么假设。

黛比：好的。如果程序员需要在编写之前阅读和理解代码，并且易于阅读和理解所讨论的代码片段，那么编写代码的难度就不受阅读和理解的束缚，而是受过程的束缚。写作本身。而且我没有足够的信息来说明该过程是困难还是容易。这就是为什么我说：“我不确定。”
沃尔特：你是对的！如果难以阅读和理解代码，那么无论需要多么困难或多么容易地进行更改，都将很难做到。而且，如果代码易于阅读和理解，那么一切都取决于所需的更改类型。

Debby：因此，如果在这种特殊情况下更改非常简单，那么难以理解的代码将使更改变得困难，而易于理解的代码将使更改变得容易。令人着迷的想法。
沃尔特：如果在这种特殊情况下很难进行更改，那么难以阅读的代码只会使情况变得更糟，而易于理解的代码将使更改保持原样。

黛比：我得出的结论是，难以阅读和理解代码总是使程序员的工作更加困难。现在，我明白了为什么您要优先考虑编写代码的难易程度。
沃尔特：那还不是全部！

黛比：是吗？继续。
沃尔特：根据我的经验，我编写的代码比阅读的代码少5-15倍。因此，可读性和可理解性具有更高的优先级。

黛比：我明白了。您说的是“一定程度的简洁”。你是什么意思？
Walter：在源代码中，很容易使某些代码更加简洁，但会牺牲可读性和可理解性。

Debby：哦，这与使代码更易于阅读和理解的原始前提相矛盾，不是吗？
沃尔特：当然可以。

黛比：您能扩大“简洁程度”吗？我可以从代码中删节些什么以使其更简洁，我不能做什么？
沃尔特：由于我们想有效地传达代码的核心逻辑，因此我们不应该修剪此类逻辑的任何部分。我们应该削减所有其他内容，包括显而易见的，重复的以及样板。

黛比：您是否更注重简洁？
沃尔特：我认为可以解决这个问题，或者至少我现在再也想不起。

黛比：好吧。谢谢，现在我明白了简洁代码的价值。
沃尔特：不客气。再见。
黛比：再见。

结论

您为什么要关心代码的简洁性？

更少的代码可以完成这项工作。
减轻了无法消除的无用重复的痛苦。
当您不能使用简洁的代码时（因为您的编程语言在设计上不是简短的），那么您的重复/重复感就会变得麻木。这会影响注意重复的代码和注意人们（以及您！）执行的重复操作，这些操作应该是自动化的。因此变得对复制/重复变得麻木，使程序员变得更糟。
当样板过多时，将很难理解（并在其中找到错误）代码的核心逻辑。它起到噪音和干扰的作用。
当您习惯于滤除样板之类的噪声时，就很难在所述样板上看到错误。
如果您可以在不牺牲编写简便性的情况下优化可读性/可理解性，那么一定要这样做！
简洁可能会被夸大，以至于损害可读性，易理解性和易写性。确保保持适当的健康平衡。

近年来，我认为我发现了一种编程语言，它在简洁，易于阅读/理解和易于编写之间取得了适当的平衡。

这种语言是科特林。而且我已经将350页的动手教程作为4部分的电子书来编写。如果您想学习它，请下载Ultimate Tutorial：Kotlin入门。