ACM通信
Kode恶性
理智vs.看不见的标记
亲爱的KV,
我的团队复活了一些旧的Python代码，并将其升级到版本3。源代码中不能混合制表符和空格的新限制使这个过程变得更糟。自动清理允许通过用空格替换制表符来执行代码，这对行尾的注释造成了很大的破坏。为什么有人会在一种语言中使用如此重要的空白呢?
白了
亲爱的白种人,
编辑过Makefile吗?尽管在编程语言中大量使用空白的传统由来已久，但所有传统都需要改变。在Python中，许多人对使用空白(而不是大括号)来表示代码块的限制提出了异议，但由于开发人员在Python版本3中没有改变他们在这方面的想法，我怀疑我们都将在相当长一段时间内坚持使用它，而且我相当肯定将有其他语言，无论大小，留白仍然很重要。
如果我能改变所有编程语言设计者心中的一件事，那就是给他们留下一个深刻的印象:任何对程序的语法或结构意义有意义的东西都必须很容易被人类读者看到，并且开发人员使用的系统也很容易理解。
让我们先解决最后一点。让工具容易理解软件的结构是拥有帮助程序员为计算机准备适当程序的工具的关键之一。从软件开发的早期开始，程序员就试图构建工具，在不可避免的编辑-编译-测试-失败-编辑无尽循环之前，在程序文本中可能出现问题的地方显示它们。代码编辑器添加了着色、语法高亮显示、折叠和许多其他特性，这是一种绝望的(有些人可能会说徒劳的)提高程序员生产力的尝试。
当一种新语言出现时，代码中的这些能指必须一致使用，这一点很重要;否则，您选择的编辑器很少或根本没有能力部署这些有用的提示来提高工作效率。例如，允许任何两个符号表示相同的概念是绝对不允许的。想象一下，如果您可以有两种类型的大括号来描述代码块，仅仅因为编程社区的两个不同部分需要它们，或者如果有多种语法方法来解引用一个变量。其基本思想是，必须有一种明确的方法来完成语言必须做的每一件事，既便于人类理解而且为了编辑器开发人员的理智。因此，在代码中使用不可见或近似不可见的标记，特别是制表符和空格，来指示结构或语法。
不可见和几乎不可见的标记将我们带到了问题的人类部分——不是说代码编辑器的作者不是人类，而是我们大多数人不会编写新的编辑器，尽管我们所有人都将使用编辑器。我们都知道，曾几何时，计算机的内存很小，制表符(一个字节)和相应的空格数(8)之间的差异可能是存储在珍贵磁盘上的源代码大小的显著差异，也可能是通过任何原始的和缓慢的总线从存储到内存的传输。
将编码标准从8个空格改为4个空格可能会改善情况，但让我们面对现实吧，几十年来这些都无关紧要。现在，使用这些不可见标记的唯一原因是清楚地表示一段代码相对于它周围的代码的范围。
事实上，最好选择一个不是制表符也不是空格且通常不在程序中使用的字符—例如Unicode编码点U+ 1f4a9—并将其用作通用缩进字符。编辑器可以根据用户的喜好自由地以任何一致的方式缩进代码。用户可以在每个缩进字符中使用任意数量的空白字符——8、4、2、某个质数，他们喜欢什么都行——程序员可以选择他们自己对作用域的看法。在磁盘上，这种格式每个缩进只需要花费一个字符(两个字节)，如果希望查看缩进字符(现代编辑器的一个常见功能)，只需按下开关，就可以看到所有的缩进字符。每个人都会很高兴，我们也最终解决了制表符与空格的古老难题。
KV
相关文章
在queue.acm.org
文件系统垃圾
Kode恶性
https://queue.acm.org/detail.cfm?id=2003323
《迷失在集市上的一代
Poul-Henning坎普
https://queue.acm.org/detail.cfm?id=2349257
演示数据作为代码
托马斯·a·Limoncelli
https://queue.acm.org/detail.cfm?id=3355565
数字图书馆是由计算机协会出版的。版权所有©2020 ACM, Inc.
评论
贡纳狼
你在文章中说，例如，允许任何两个符号代表相同的概念是绝对不可以的。这让我想起了一个案例，在这个案例中，反驳你的建议实际上是一种进步。
许多年前，我学习了一种Lisp方言，其中括号、方括号和括号的句法意义是相同的，它们只需要匹配(也就是说，没有括号可以关闭括号)。这确实提高了程序的可读性/可维护性，因为它可以更好地发现您在深层s表达式的何处工作。
当然，把Lisp带进任何关于可读性的讨论中感觉像是作弊。在Lisp中，淹没在一层又一层的“脚趾甲修剪”中太常见了。
当然，唯一比Lisp更糟糕的是“空白”编程语言，它引入了一个新概念，即任何非空白字符都被认为是注释，并且语言定义由空格、制表符和换行符的组合组成。是的，当然，空白语言作为一种“深奥的编程语言”占据了一席之地，用于证明观点和设置编程挑战，但仅此而已。
显示1评论