Everything from Python to C++ supports non-ASCII idents by default. It's the correct behaviour. —— Graydon Hoare，Rust語言設計者
譯：“從Python到C++都默認支持非 ASCII 碼標識符。這是正確的作為。”
2018年10月31日，Rust 語言歷史上最受爭議的 RFC 之一在經歷了將近5個月的爭辯和修訂後，終於圓滿完成。
684條評論，75人參與。雖未親歷，但前事不忘後事之師。此文就來回顧這個 RFC 以及那些激烈碰撞的聲音。
什麼是非 ASCII 碼標識符
ASCII 碼問世於20世紀六十年代。標準 ASCII 碼只有 128 個，僅包含了英文字符與其他少量標點、運算等特殊符號。多數現今常用的編程語言在上世紀被設計出來時，設計者和使用者也大多數在英文母語國家，因此早期並不支持使用英文之外的語言文字來命名代碼中的標識符。
時至今日，有不少國內開發者還認為，在代碼中必須用英文命名變量，因此代碼中會出現 redEnvelope 甚至 hongbao 這樣的命名。
但實際上大多數英文編程語言早已支持使用英文之外的字符命名變量、方法、類名等等。比如 Python3 中完全可以這樣寫：
紅包金額 = 888
紅包數 = 5
開銷 = 紅包數 * 紅包金額
蘋果公司主導的 Swift 編程語言官網的手冊中，也用了中文和其他符號進行命名演示：
此文的主角，RFC#2457 就是為了讓 Rust 語言也具備這一特性。
RFC#2457
2018 年六月三日 10 點 25 分（太平洋時間）， PR 2457 被 pyfisch 創建，開始了這個 RFC 的審議過程。
題目很直接：“Allow non-ASCII identifiers”——“允許非 ASCII 標識符”。在它的初稿中，在“動機”部分開篇，指出了“許多開發者的英文並不流利，使用母語命名標識符使得寫和讀代碼更輕鬆。”
更引用了 Python 語言於 2007 年的 PEP 3131：
Such developers often desire to define classes and functions with names in their native languages, rather than having to come up with an (often incorrect) English translation of the concept they want to name. By using identifiers in their native language, code clarity and maintainability of the code among speakers of that language improves.
（並不熟悉英文語言的）開發者常希望用他們的母語定義類和函數，而不是被逼著用（往往是不正確的）英文翻譯來命名一個概念。通過用母語命名標識符，對同一母語的開發者來說，代碼清晰度和可維護性得以改進。
RFC 的更多篇幅包含相關的技術細節，有興趣的可以深究。本文更關注的是 684 個評論中佔大多數的對該 RFC 初衷的質疑（尤其是來自於華人開發者的）以及相應回應。
風波起
RFC 提交審議的當日下午4 點，一位 Rust 項目參與者 mark-i-m 提出了首個異議，表示（非 ASCII 碼）字符難打以及有時會顯示亂碼。並在之後用教學經歷闡釋：有時學生從網上拷貝的代碼段中有無法顯示的 unicode 字符（其中誤稱 Java 不支持非 ASCII 碼標識符）；有位教授喜歡用希臘字符在 Julia 代碼中命名，而 ta 本人輸入這樣的字符非常麻煩。
接著，一位標示為中國廣州的學生 shingtaklam1324 提出，中文字符會在不支持 unicode 的某些編輯器上變為亂碼。pyfisch 回應：編譯器支持 UTF-8編碼的源代碼文件，修改編輯器設置即可。
四日 10 點，一位 Rust 組織成員 joshtriplett 提出個人立場：希望標識符命名僅限於 ASCII。他之後發佈了一系列跟帖，在七月二十六的總結中，提到他由於源碼中出現非 ASCII 碼的字符導致各種調試的麻煩，但未給出具體例子。他在四日的一個帖中的發言很有代表性：
It's a tradeoff between "should people be able to write identifiers in languages that can't be represented in ASCII" versus "should people be able to read arbitrary code". Both of those are important, and I don't want to discount either, but I'd favor the latter.
在“人們能用英文之外的語言寫標識符”和“人們能讀懂任何代碼”之間權衡，雖然兩者都很重要，但我更偏向後者。
這種“天下皆（應）會英文”的思維很常見，似乎英文標識符就能被世界上所有人讀懂。要知道，世界上有八成多的人口並不會英文。
立刻，來自 Mozilla 的開發者 SimonSapin 回應：
it is up to the author of a given piece of code to make that choice. It is not our place to dictate what language people should speak or write in contexts we can’t even think of.
這（用母語還是英文命名）應該是代碼作者的選擇。我們（語言設計者）並不該裁斷開發者用什麼語言讀寫代碼，尤其是在我們料想不到的場景下。
5 日，Ixrec 提問：“真的會有人在實用項目代碼中用非 ASCII 標識符嗎？”他還提到，他是佔全世界會日語的 58%的美國男士之一，但他也想不到除了日語在寫註釋之外的用處。
來自 Mozilla 的 Manishearth 回應稱，代碼中看到過一些歐洲語言如葡萄牙文；暫沒看到中文或俄語的，但看到過註釋中使用。有些日語和葡萄牙語英文化後的代碼，可見的確有使用非 ASCII 碼命名的需求。另外，中國有個龐大的 Rust 社區，並未與英語 Rust 社區有太多交流。他在中文 Rust 的 QQ 群眾徵求過相關意見，有幾方面收穫：
- 限於工具，代碼中不用中文
- 有時在新手教程中使用
- 大多數人不用中文命名
他的結論是，至少益處是使得音調可以使用，比如 método。
接下來是來自中國廣州的 huangjj27 指出，輸入法切換會降低寫代碼的效率。不過也提到更多人會因此學 Rust。希望將此特性作為選項，而非標配。
又一位座標北京的 crlf0710 表示，大陸主流沒有使用非 ASCII 碼命名。偶爾用拼音的會被認為不專業。易語言有用戶，但並未進入主流。新手教程有用，但也許需要改名關鍵字，使文字看起來更一致。也希望特性作為用戶可選項，而非標配。
又是北京的 ZhangHanDong 乾脆來一句“絕對不要！”
座標加州的 KiChjang 表示，一些中國 Rust 用戶擔心生態被分裂。比如某個庫用的語言是用戶不知如何輸入的。
Manishearth 對此回應：早已有大量庫除了命名之外的所有文檔都用非英文編寫，比如騰訊的 wepy，他就不會用。用了中文命名之後，也不會更糟。如果一個庫流行到有英文文檔的程度，很可能那時也會用英文命名了。至於如果庫用了不認識的語言，那就——不用。
至此，華人開發者，成為一個批量發聲反對此特性成為標配的群體。
下面，Manishearth 獲得一些葡萄牙 Rust 社區反饋，表示聽到不同意見。也得到了一些使用葡萄牙語的代碼例子，包括 C++，Java 和 PHP。
來自韓國的 kimhyunkang 回應 lxrec：之前在韓國公司工作時，看到一些 C++ 和 Java 開發者用英文化的韓語命名，原因是需求文檔是韓文寫的，而不少術語很難翻譯成英文，因為韓語沒有從拉丁文或者希臘文借用的詞語，而英語沒有從中文借用的詞。如果要翻譯成英文，命名更長也更不可讀。
est31 提供了一些使用德文命名的 Java 和 PHP 代碼。
來自北京的 3442853561：工作中不應用（中文命名），但不支持的話會顯得 Rust 不合群（很多其他編程語言都支持），也對新手不友好。建議設置為對新手默認使能，老手可關閉。
接下來是來自瑞士的 eggrobin 以他的用非 ASCII 碼和非英文標識符的親身經歷，包括在編寫編程書籍的例程中使用法語等等。
欲知後事如何，且聽下回分解！
【寫到這裡，已經三個多小時，遠遠超出了兩小時寫完的預計。而上面僅僅瀏覽了前三天內的 20 多個評論，已經有了很多收穫。決定分為一個系列進行連載，如期待後文，敬請關注本號！】
閱讀更多 用中文編程 的文章
