PDF一逗之差，意义顿失
标点符号与软件开发有何关系？
Jef Raskin，芝加哥大学
出版界发生过更奇怪的事情，但也不多。亚马逊畅销书排行榜（在我写作时）的榜首是 Lynne Truss 关于……标点符号的书。它比《哈利·波特》更畅销。从书名《Eats, Shoots and Leaves》（Gotham Books，2004）开始，当省略逗号时，书名含义会发生巨大变化，这本书以一种有趣的方式漫谈了正确和清晰地使用标点符号进行写作的优点。
那么，为什么要在 中讨论一本关于标点符号的有趣书籍，即使它很受欢迎呢？部分原因是大多数软件文档的糟糕状况。清晰和精确在我们这个领域至关重要。正如我们这个时代最优秀的程序员之一 Donald Knuth 在《文学编程》（剑桥大学出版社，1992 年）中指出的那样，在用代码编写之前，先用英语（或您喜欢的自然语言）写下我们的算法意图是有益的。
如果为我工作的程序员和与我一起学习的学生知道“its”和“it’s”的区别，以及何时使用破折号来连接复合形容词，我将非常高兴。 需要的是能够明确表达你的意图。 这并不容易，但研究这方面的书籍会有所帮助。 我将以给作者的公开信的形式介绍 Truss 女士的书（以及另一本书）。
尊敬的 Truss 女士：
您最近的书籍《Eats, Shoots and Leaves: The Zero Tolerance Approach to Punctuation》令人钦佩且可读性强。 我一直觉得我们民众糟糕的标点符号运用能力令人费解。 我希望您的书的流行能够改善这个问题。 您的基本论点是，良好的标点符号可以实现清晰、明确的沟通——“防止作者和读者之间产生尴尬的误解”。 预防误解在悬疑小说或杂志文章中可能很重要，但在技术写作中则更加重要，因为“尴尬的误解”可能会演变成代价高昂的错误。
您能提到我创建的产品 Macintosh 电脑真是太好了，我很高兴您使用它。 您提到，您在使用这台机器多年后才发现您可以输入正确的破折号。 如果您知道它是作家设计的（或者它附带了一本像样的纸质手册），您可能期望从一开始就找到完整的破折号系列。 您在书中提到的所有三种破折号（连字符、连接号和双破折号或长破折号）都包含在内。 令我惊讶的是，您省略了连接号的一种用法，即当它在多个形容词之间建立层次结构以共同修饰名词时。 但幸运的是，所有这些信息以及更多信息都可以在另一本关于清晰写作的古怪、权威且偶尔非常有趣的书籍中找到，并且这本书专门针对我们这些从事科学和技术领域的人：Lyn Dupré 的杰作《Bugs in Writing: A Guide to Debugging Your Prose》（第二版，Addison-Wesley，1998 年）。
奇怪的是，您只提到了省略号的两种用法，而省略了第三种：表示序列的延续：例如，Jan, Feb, Mar, ...。 为了完整起见，您还应该告诉读者，如果显示了序列的结尾，则省略号后需要逗号：2, 4, 6, ..., 22。 在本书的结尾，您似乎责骂计算机领域是英语被带到枷锁示众并被鞭打至鲜血淋漓的地方。 但是，作为补偿，今天的计算机用户可以访问真正的省略号，而无需使用三个连续的句点（或者我们在这里称之为句号）。 对于那些了解标点符号的人来说，计算机——与过时的打字机不同——使他们能够获得接近专业水平的排版精确度和控制力。 从这个意义上说，计算机是对正确标点符号的帮助，而不是障碍。
这种优势的缺点是一些出版商要求您根据他们的规范提交“可直接制版的稿件”。 这给作者带来了排版负担，如果作者使用的文字处理器与出版商预期的不同，这可能是难以承受的。
我非常同意您的观点，即“美国式”的做法，即将标点符号强行放在结束引号内是荒谬的。 在我最近的一本书中，我坚持在这方面采用英国用法； 它具有非常大的逻辑优势。 我们可能把你们的茶叶扔进了波士顿港，但这并不是不接受你们标点符号的理由。 在我的例子中，我被允许违反内部风格规则，因为我写的是一个精确性胜过风格的主题：人机界面。
例如，微软的 Windows 软件会告诉您“要停止打印，请按 Control + .”。 我认为，清晰性要求前一句中结束引号周围都有句点。
这里的重点是，由于对标点符号的疏忽，微软提供的建议是模棱两可的。 是要按下 Control 键，然后再按加号键（读者假设句点在那里结束句子的情形）吗？ 我第一次尝试了，但很失望。 还是说要按住 Control 键，然后点击加号，然后再点击句点？ 那也失败了。 最后，我猜加号的意思是“按住并点击”。 如果它说“要停止打印，请按住 Control 键并点击句点键。”，就不会有什么问题了。
也许并非所有程序员都是文盲，只是写指令的人是文盲。
我会更强烈地为“序列”逗号辩护，而不是像您那样对它们采取放任自流的态度。 我会说，理由是，这些逗号消除了潜在的歧义，而省略它们没有任何好处。 例如，由于我不了解酒精饮料的世界，当被指示“给我们拿螺丝刀、马提尼、雪利酒和苏打水”时，我不确定自己是被要求提供三种还是四种饮料。 您确实提出了这一点，但未能坚持这一点。 除非规则始终如一地应用，否则您在任何特定情况下都不知道指的是哪种。 我的规则是，列表中的每个项目都应该有自己的逗号； 最后一个不应该意味着被剥夺。
似乎您偶尔不理解计算机惯例的基本原理。 例如：人们并非“尝试”使用星号 *强调* 而不是斜体。 只是有些计算机系统无法准确传输斜体，而星号可以畅通无阻地从一台机器传输到另一台机器。 您说“新技术”以“非线性的方式，通过指数级的横向关联系列”呈现信息。 它看起来只是那样； 我们以线性方式处理材料； 我们是生活在线性时间中的生物。 当您滚动文本时，“您的眼睛保持静止，而材料流过”也是不正确的。 事实上，您滚动并停止，然后才阅读，并且您以正常方式阅读。
当您说“您不能在屏幕的边距上写下注释供五十年后的另一位读者发现”时，我想您可能没有见过主题讨论和“维基”。 我不仅可以添加边注，而且由于 Web 的双向性质，评论可以成为所有后续读者看到的内容的一部分，而不仅仅是我的副本的偶然读者。 例如，我对《斯坦福哲学百科全书》（http://plato.stanford.edu）所做的一条评论被纳入了作品（并给予了应有的荣誉）。 然而，我对我的纸质版 OED（《牛津英语词典》）所做的边注不太可能被如此容易地纪念。
我认为，认为互联网“不能用作压迫工具”是天真的。 在许多国家，互联网受到严格控制，因此恰恰是这样一种工具。
对我以及我认识的许多其他人来说，计算机不是敌人，而是促进良好写作的动力。 也许它使写作能力的低下状态更加明显，但我不认为它使情况变得更糟。
对您的书的最后一个批评：它没有索引。 我想借此机会说，计算机可以为您生成一个索引。
抛开这些小问题不谈，我希望许多计算机同行能够遵守您的明智规定。 要使文字成为忠实的仆人，能够忠实地将您想要表达的含义从您的脑海传递给读者，这是一项艰苦的工作。 强有力地应用位置恰当且选择得当的标点符号始终是保持它们履行职责所必需的。
喜欢或讨厌？请告诉我们
[email protected] 或 www.acmqueue.com/forums
JEF RASKIN，芝加哥大学计算机科学兼职教授，以其著作《人性化界面》（Addison-Wesley，2000 年）和在 Apple 创建 Macintosh 项目而闻名。 他拥有多项界面专利，为世界各地的公司提供咨询服务，并经常被邀请在会议、研讨会和大学演讲。 他目前的项目“人性化环境”（http://humane.sourceforge.net/home/index.html）正在计算机科学界和商界引起关注。
© 2004 1542-7730/04/0700 $5.00
最初发表于 Queue 第2卷，第5期—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑非密码散列函数评估标准
尽管密码散列函数和非密码散列函数无处不在，但在它们的设计方式上似乎存在差距。 存在许多受各种安全要求驱动的密码散列标准，但在非密码方面，存在一定程度的传统知识，尽管散列函数历史悠久，但尚未得到充分探索。 虽然针对现实世界数据集的均匀分布非常有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 实践
随着领导者在财政紧缩和人工智能等变革性技术的背景下寻求优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。 技术领导者凭直觉接受，良好的开发者体验能够实现更有效的软件交付和开发者幸福感。 然而，在许多组织中，为改善 DevEx 而提出的倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果来研究生产力差异，从而为该主题提供新的见解。 低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。 本文报告了程序和协议、结果、局限性以及未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来为商业和社会服务，但它也很健忘。 在其快速前进的过程中，它容易受到时尚的异想天开的影响，并且可能会忘记或忽略针对其面临的一些永恒问题的行之有效的解决方案。 用例于 1986 年首次引入，后来普及，是这些行之有效的解决方案之一。
© 保留所有权利。