缩进使软件控制流程明显。你怎么看？

Question

您遇到过多少次在代码深处带有 return 语句的函数？或者没有注意到循环中的 break 或 continue？虽然我最近没有被return吓到，但我仍然被continue和break打了个措手不及。

本科毕业后不久，我向 Dennis Ritchie 建议修改 C 的 break 语句。虽然我不再希望发生变化，但丹尼斯的回应具有更广泛适用的智慧：

您之前提出的建议，即“break”语句应增加一个数字以指示要逃脱的级别数。这是我和 X3J11 委员会都仔细考虑过的一个想法，它在几个方面都很有吸引力。然而，语言标准化委员会决定拒绝它。 这个想法的一个固有问题是它加剧了“中断”已经存在的困难，即难以确定控制的去向。源程序中非常小的变化会导致控制流发生巨大变化，并且混乱会随着中断级别的数量而增加。 [强调我的]

我相信问题不在于 break 和其他控制流语句。问题是我们如何缩进这些语句。缩进不应来自控件所在的级别。相反，缩进应该达到控件所达到的水平。所以，而不是

func(....) {
    …
    for (...) {
        …
        if (...) {
            break;
        }
       …
    }
    …
}

我建议我们缩进如下

func(....) {
    …
    for (...) {
        …
        if (...) {
    break;
        }
       …
    }
    …
}

上面的代码看起来很难看，而这正是重点。

通过像往常一样缩进，我们可能会掩盖意外行为。通过按提议缩进，我们做出了意料之外的事情。这将使所有人更好地理解代码，并改善夜间睡眠。

我不知道丹尼斯会怎么想。可悲的是，我从来没有得到他的帮助。但是，如果您喜欢这个想法，作为对丹尼斯的致敬，我想以他的名字命名。 K&R style of indentation 已经归功于他了。将此称为 Ritchie 缩进 会让人感到困惑。因此，我建议我们将此称为 Ritchie 流表观 (RFA) 选项。有很多缩进标准，这适用于大多数。代码编辑器、存储库代码查看器可以在单击 RFA 按钮时切换缩进。如果人们喜欢，这个选项也可以添加到代码格式化程序中。

请让我知道您对此有何看法？

我最初在medium上写这篇文章。它有丹尼斯·里奇 (Dennis Ritchie) 的原始信件的扫描件。

想听听人们对此有何看法？此外，如果人们喜欢它并支持它，他们是否有能力帮助围绕它创建工具？