反對語法高亮的情況

        英文原文：A case against syntax highlighting  譯/臘八粥

        在開發軟件的時候，你依賴語法高亮嗎？如果是，那么你或許正搬起石頭砸自己的腳。本文，我將討論審美上誘人的語法高亮，把關注點從內容遷移到了形式，阻礙閱讀代碼的人盡量去理解代碼。

一個語法高亮的例子

        背景

        語法高亮是大部分現代文本編輯器和開發環境的標準特性。基本思路是在多種語法元素之間增加視覺上的區別，降低程序員區分關鍵詞、標點符號和變量名稱之間的難度。

        為什么語法高亮首先被發明了呢？在程序員閱讀代碼、思考“)”可能是一個變量名或者預處理器指令的時候，會混淆語法嗎？當然不會。閱讀計算機程序常常不那么容易，難度來自于程序的錯綜復雜，而非語法。

        易讀性

        或許發明語法高亮是為了加快閱讀速度。是的，一定是這樣的，高亮的代碼必須更容易閱讀。畢竟，它是彩色的！

        哦哦，不是。排版中的翻閱有個基本規則，當閱讀一段文字時，你應該選擇一種字體并持續下去。同樣，一點點的顏色可能抓住了讀者的注意力，不過它 將不可避免地降低文本的易讀性。文本的自然流被破壞了，需要花費更多的腦力把個別的字母組成單詞和語義。從認知上看，閱讀過程稍微少了些不假思索，稍微多 了些注意；用來實際理解文本的、有意識的部分，少了一些空間。

語法高亮應用到小說里。定位所有的動詞是容易了，但是你究竟要鬧哪樣？

        語義比語法更重要

        閱讀代碼時，理解最重要。與小說或報紙不同，你可以跳過整段并了解其大概，軟件卻不可避免地充滿了你不得不花時間去理解的復雜性和重要的細節。為此，你需要在語義層面審視代碼。

        甚至他們已經相當熟悉代碼了，大部分開發人員寧可碰到（和修復）內存泄露、安全漏洞和低效的算法，而不是純粹的語法錯誤。無論如何，語法錯誤將 被編譯器發現；開發人員不應該在它們身上浪費時間。但是，如果語法高亮使他們的心智偏向了代碼語法而不是代碼意義，那么他們為什么還要那樣呢？

        我不是說開發人員愚蠢。但是既然我們時不時地錯過偶然的 bug——每個人都犯錯——我認為我們應該配置幫我們找到 bug 的工具，而不是幫助我們錯過 bug。

        學習曲線

        或許語法高亮不是為有經驗的程序員準備的，或許引進它是為了讓新手的學習曲線變得平緩，但是非常像某些不明智的鋼琴老師把彩色貼紙粘到琴鍵上。 我假設鋼琴老師是這樣溝通的（“現在按下黃色的鍵”，而不是“現在按F”），但是老實地講，他們相信孩子不能學會音符名字嗎？最終，他們將不得不忘記這些 帶有顏色的貼紙。

        同樣現象也出現在用戶界面向導。一個高級操作，比如圖像處理程序，是復雜的，復雜程度讓新用戶感到困擾。進入向導對話框，它將跳過或自動化一些 步驟，代價是犧牲了靈活性。最終，用戶只是學會了如何使用向導，而不是復雜的功能本身，因此額外的靈活性被失去了。故，你根本不能讓學習曲線扁平化，因為 你正在繞過它。

        如果學習在有顏色的環境下編寫軟件，你很可能發現沒有顏色的代碼閱讀起來有困難、甚至在不同的顏色體系。從這個角度看，語法高亮是教育的死胡同。就像學習如何騎帶有輔助輪的自行車，在你忘掉那種方式學到的某些技巧之前，你是不能騎著真正的自行車的。

帶輔助輪的自行車

        例外

        語法高亮能夠實際貢獻力量的情況有兩種。第一個是多行注釋。如果你在源代碼文件里掃視，你可能在一大塊注釋掉的代碼中間停住，你開始把它視作代碼，過了一會兒，你碰到注釋結束的符號，這才意識到你剛才一直在閱讀注釋。對于這種情況，用不同的顏色呈現所有注釋將防止該錯誤的發生。

        另一方面，這將是短暫的解決方案。大部分人認為注釋掉代碼應該被視作一種非常暫時的 debug 技巧，遲早那些注釋掉的代碼必須被刪除或重寫。改變顏色、讓它從眼前消失就像在掩蓋。

        第二種情況主要和C語言有關。意外的寫成“=”而不是“==”會導致難以發現的 bug，因為你坐在那里瞪著屏幕很長時間了卻對其視而不見。這是我發現的唯一情況，你能夠關注代碼的語法級別，并從中受益，而不用太關注語義環境。語法高 亮用不同的顏色標記“=”和“==”是可能的。天啊！這是實施語法高亮的一個絕佳理由！但是——在這一點上，它可能沒有讓你感到驚奇——我碰到的每個顏色 體系都用同一種顏色高亮“=”和“==”。

        結論

        語法高亮沒有提高易讀性，它鼓勵你在代碼上跳躍，而不是理解它；它也讓你關注語法錯誤而不是真正的 bug；它阻礙了你學習。據論證，它甚至鼓勵你拖延注釋掉的代碼塊的刪除工作。目前的方案均沒有區分“=”和“==”，這是語法高亮唯一可以大顯身手的狀況。

        是誰發明了這么一種可怕的功能？我最好的預測是，因為它易于實現，所以才出現并作為一種酷炫的想法。現在它已經成為賣點；人們不贊同那些不支持語法高亮的編輯器，即使沒有它更好。這是一種足夠普通的現象；例子包括半透明的控制臺窗口和其它養眼的東東。

        我推薦你服下紅藥丸：在沒有語法高亮的情況下編輯你的代碼，至少要接受只有兩種顏色（一種是代碼，一種是注釋）的最簡化的方式。注意，沒有彩色的外衣，你的代碼實際上可能看起來要丑陋些，但是至少你能看到它的真面目。

        皇帝這次沒有裸體，他正穿著一套讓人驚奇的、絢麗的小丑衣服。

                    <span id="shareA4" class="fl">                  
                        </span>