反对语法高亮的情况

        英文原文：A case against syntax highlighting  译/腊八粥

        在开发软件的时候，你依赖语法高亮吗？如果是，那么你或许正搬起石头砸自己的脚。本文，我将讨论审美上诱人的语法高亮，把关注点从内容迁移到了形式，阻碍阅读代码的人尽量去理解代码。

一个语法高亮的例子

        背景

        语法高亮是大部分现代文本编辑器和开发环境的标准特性。基本思路是在多种语法元素之间增加视觉上的区别，降低程序员区分关键词、标点符号和变量名称之间的难度。

        为什么语法高亮首先被发明了呢？在程序员阅读代码、思考“)”可能是一个变量名或者预处理器指令的时候，会混淆语法吗？当然不会。阅读计算机程序常常不那么容易，难度来自于程序的错综复杂，而非语法。

        易读性

        或许发明语法高亮是为了加快阅读速度。是的，一定是这样的，高亮的代码必须更容易阅读。毕竟，它是彩色的！

        哦哦，不是。排版中的翻阅有个基本规则，当阅读一段文字时，你应该选择一种字体并持续下去。同样，一点点的颜色可能抓住了读者的注意力，不过它 将不可避免地降低文本的易读性。文本的自然流被破坏了，需要花费更多的脑力把个别的字母组成单词和语义。从认知上看，阅读过程稍微少了些不假思索，稍微多 了些注意；用来实际理解文本的、有意识的部分，少了一些空间。

语法高亮应用到小说里。定位所有的动词是容易了，但是你究竟要闹哪样？

        语义比语法更重要

        阅读代码时，理解最重要。与小说或报纸不同，你可以跳过整段并了解其大概，软件却不可避免地充满了你不得不花时间去理解的复杂性和重要的细节。为此，你需要在语义层面审视代码。

        甚至他们已经相当熟悉代码了，大部分开发人员宁可碰到（和修复）内存泄露、安全漏洞和低效的算法，而不是纯粹的语法错误。无论如何，语法错误将 被编译器发现；开发人员不应该在它们身上浪费时间。但是，如果语法高亮使他们的心智偏向了代码语法而不是代码意义，那么他们为什么还要那样呢？

        我不是说开发人员愚蠢。但是既然我们时不时地错过偶然的 bug——每个人都犯错——我认为我们应该配置帮我们找到 bug 的工具，而不是帮助我们错过 bug。

        学习曲线

        或许语法高亮不是为有经验的程序员准备的，或许引进它是为了让新手的学习曲线变得平缓，但是非常像某些不明智的钢琴老师把彩色贴纸粘到琴键上。 我假设钢琴老师是这样沟通的（“现在按下黄色的键”，而不是“现在按F”），但是老实地讲，他们相信孩子不能学会音符名字吗？最终，他们将不得不忘记这些 带有颜色的贴纸。

        同样现象也出现在用户界面向导。一个高级操作，比如图像处理程序，是复杂的，复杂程度让新用户感到困扰。进入向导对话框，它将跳过或自动化一些 步骤，代价是牺牲了灵活性。最终，用户只是学会了如何使用向导，而不是复杂的功能本身，因此额外的灵活性被失去了。故，你根本不能让学习曲线扁平化，因为 你正在绕过它。

        如果学习在有颜色的环境下编写软件，你很可能发现没有颜色的代码阅读起来有困难、甚至在不同的颜色体系。从这个角度看，语法高亮是教育的死胡同。就像学习如何骑带有辅助轮的自行车，在你忘掉那种方式学到的某些技巧之前，你是不能骑着真正的自行车的。

带辅助轮的自行车

        例外

        语法高亮能够实际贡献力量的情况有两种。第一个是多行注释。如果你在源代码文件里扫视，你可能在一大块注释掉的代码中间停住，你开始把它视作代码，过了一会儿，你碰到注释结束的符号，这才意识到你刚才一直在阅读注释。对于这种情况，用不同的颜色呈现所有注释将防止该错误的发生。

        另一方面，这将是短暂的解决方案。大部分人认为注释掉代码应该被视作一种非常暂时的 debug 技巧，迟早那些注释掉的代码必须被删除或重写。改变颜色、让它从眼前消失就像在掩盖。

        第二种情况主要和C语言有关。意外的写成“=”而不是“==”会导致难以发现的 bug，因为你坐在那里瞪着屏幕很长时间了却对其视而不见。这是我发现的唯一情况，你能够关注代码的语法级别，并从中受益，而不用太关注语义环境。语法高 亮用不同的颜色标记“=”和“==”是可能的。天啊！这是实施语法高亮的一个绝佳理由！但是——在这一点上，它可能没有让你感到惊奇——我碰到的每个颜色 体系都用同一种颜色高亮“=”和“==”。

        结论

        语法高亮没有提高易读性，它鼓励你在代码上跳跃，而不是理解它；它也让你关注语法错误而不是真正的 bug；它阻碍了你学习。据论证，它甚至鼓励你拖延注释掉的代码块的删除工作。目前的方案均没有区分“=”和“==”，这是语法高亮唯一可以大显身手的状况。

        是谁发明了这么一种可怕的功能？我最好的预测是，因为它易于实现，所以才出现并作为一种酷炫的想法。现在它已经成为卖点；人们不赞同那些不支持语法高亮的编辑器，即使没有它更好。这是一种足够普通的现象；例子包括半透明的控制台窗口和其它养眼的东东。

        我推荐你服下红药丸：在没有语法高亮的情况下编辑你的代码，至少要接受只有两种颜色（一种是代码，一种是注释）的最简化的方式。注意，没有彩色的外衣，你的代码实际上可能看起来要丑陋些，但是至少你能看到它的真面目。

        皇帝这次没有裸体，他正穿着一套让人惊奇的、绚丽的小丑衣服。