對在程式碼中使用中文命名的質疑與迴應
原文在中文程式設計知乎專欄: 對在程式碼中使用中文命名的質疑與迴應
對在程式碼中使用中文命名的質疑與迴應
有一部分質疑同樣適用於英文程式碼, 比如"從命名看不出型別", "命名可能詞不達意"等等, 另外還有未經證實的"中文程式碼導致的未知錯誤"和沒有根據的”比英文程式碼執行慢“等等, 就不一一回應了.
沒有好處
答：如之前的13年後的共鳴-在程式碼中用中文命名的優勢和問題一文所述，中文命名在很多時候可以更準確，也比英文命名更輕鬆。
如果認為API以及內部方法/變數的命名無關緊要. 有不少可讀性相關的文章對這個誤區進行了闡述, 比如
不利於非中文程式設計者貢獻
答：現狀是, 中文開發者主創的開源庫/框架, 絕大多數的貢獻者也都是中文開發者, 即使非常流行和國際化的框架如vuejs也是如此. 原因肯定是多方面的. 能夠想到的有:
- 有類似功能的國外開源專案. 作為外國程式設計師首選參與的肯定是那些
- 如果是和中文字身相關的庫, 如結巴分詞, 主要的使用者也是中文開發者, 自然維護的也是
個人也不贊成100%的中文化. 需要和國外交流的專案肯定有. 大膽假設:以中文為母語的所有程式設計師,從事的專案中,90%是單人專案(*),剩下的10%中,90%只有同樣是中文為母語的程式設計師參與.這樣,只有1%的專案有用英文寫程式碼的硬性需要.為了這1%的需要,而在剩下的99%中使用英文,得不償失.
注： 根據Fun with GitHub repositories statistics, github上的1-contributor repository大約是60%. 當然還有很多專案沒有開源. 上面的90%仍然是假設.
當然希望看到更多的國外開發者參與國人初創的專案. 不過，除去預測得到是否會有國外開發者參與的情況, 剩下的自己發起的專案, 首要考慮的是對自己的開發和維護最有利的程式設計方式. 因為在可以預見的將來, 我自己會是最主要的貢獻者. 如果我自己的開發和維護成本隨著專案變大而變得不可持續, 那麼在專案成型和能夠吸引其他開發者參與之前可能就夭折了. 個人的感覺是用中文命名是我更熟悉和容易的方式.
osc上一些即使很熱火的開源框架, 比如JFinal, 大多隻有極少的其他開發者貢獻. 個人認為一個很重要的原因, 就是程式碼閱讀的難度, 而英文命名是一個額外的障礙. 也許對於開發者本人來說, 隨著專案的開展, 一些開始時有些彆扭的英文命名自己也習慣了, 但是對於剛拿到整個程式碼的新開發者, 任何不妥當的英文命名都會導致迷惑和時間的浪費. 為了吸引理論上的國外開發者參與, 而不優先選擇對身邊的中文開發者(包括自己)閱讀程式碼有利的程式設計方式, 個人認為這種思路是很值得商榷和分情況探討的.
芬蘭人Linus，使用英語而非自己的母語來編寫Linux程式碼
答：Linus的母語是瑞典語，根據wiki使用者是八百七千萬。中文（普通話）的母語使用者是九億五千萬。這是一百倍的差距。另外，英語母語使用者是3億六百萬。更重要的是，中文母語使用者基本集中在中國，而英語分佈在不同國家。西班牙語也類似。從人口基礎來看，用中文程式設計是非常有潛力的。
附上中文註釋就夠了
答：關於註釋和命名, 在個人之前的工作環境裡, 是第一次接觸正式的可讀性稽核. 有個印象是, 稽核員會盡量傾向於減少註釋量, 而強調程式碼本身的可讀性(其中最重要的因素之一就是命名). 稽核裡會不時出現"這個方法名已經self-explaining了,註釋就不用了"之類的評語. 雖然沒有當面確認過, 但寫註釋和維護註釋的額外工作量應該也是這種傾向的動因之一.
絕大多數API, 包括標準庫都是英文的
答: 沒錯, 但在程式碼中, 自己定義的類/方法/變數佔的篇幅一般都不少於依賴庫(包括標準庫)的方法/類所佔篇幅, 歡迎提供具體統計資料. 可以看看這裡的中英文程式碼篇幅的比例. 中文命名帶來的程式碼改變是一目瞭然的. 更關鍵的是, 自定義的部分往往是業務邏輯最集中並且最需要可讀性的部分.
如果關鍵詞還是英文, 用中文命名就沒有意義
答: 用中文命名帶來的好處是不分程式語言的, 甚至英文關鍵詞和中文的顯著區別可能帶來額外的可讀性增強. 另外, 至少短期內(5-10年), 英文關鍵詞的程式語言還將在市場中佔有不可忽視的份額, 在這個階段使用中文命名是一條代價小而收益相對立竿見影的途徑.
程式語言本身和英文語法無關
答: 雖然和英文自然語言相去甚遠, 但仍然有不少設計是帶著很多英文風格的. 如: 空格作為分隔符; for…in等用法帶有英文語法特色. for原意並沒有迴圈的意思，而更接近”對於"，這在”for（A in B）“的語法中更明顯，對應中文接近”對於B中的那些A“。while原意也沒有‘迴圈’的意思，中文接近“只要”或者“當”。這恰恰說明了英文程式語言的設計與英文語法和詞意的相關性。不懂英文的開發者在學習時就只能強記這些關鍵詞（雖然也不是大麻煩），但假想這些關鍵詞如果開始就是中文，那麼肯定會更容易理解，也省去了強記的一步。
中文輸入太慢, 降低開發效率
答: 首先, 如果考慮推敲命名的時間, 對母語是中文的程式設計師, 中文命名應該比能夠更恰當更快, 綜合各種因素哪種方式寫程式碼更快還待實踐證實. 其次, 鑑於開發過程在整個軟體生存週期中只佔一小部分, 其他的部分(設計,除錯,測試,維護)從良好的可讀性獲取的利遠大於開發效率可能降低的弊.
為避免頻繁切換中英文: 為了在輸入中文的同時不用切換就可以輸入特殊符號(){};等等, 搜狗輸入法支援"中文時使用英文標點"
會有各種漢字編碼問題導致亂碼
答：漢字編碼問題不僅限於程式碼, 使用的越少越不利於問題解決. 多數問題能通過使編碼一致避免, UTF8和GBK互轉的問題(例項)可能會在長時間記憶體在。用中文命名能使這些問題更加凸顯，促進問題解決，而不是拖延迴避.
看多了中文程式會影響英文學習，以及程式設計師前程
答：就像搞學術的需要的時候自然逼著看英文刊物，有硬性需要的時候自然會去看國外網站。如果這就會影響，那麼也許本來就不那麼需要。
中英混用的問題
比如Java中有個迴避不掉的問題JavaBeans規範一定要使用set/get命名。maven版本號的 -SNAPSHOT 特殊語義，舊junit中需要測試的方法必須以test開頭等
答: 確實在實踐中碰到混用的情況, 個人基本上是能用多少中文就用多少. 比如這裡set/get和中文混用，個人覺得可以接受。如果想在Java裡用中文編寫程式碼, 中英混用是不可能避免的.
上面列出的之外， (轉載)發展中文程式設計的意義：讓大眾化程式設計促進軟體產業的建設也對一些質疑作出了迴應
沒有先例
答: 這個 2017 年的 quora 答案(Alan Mellor’s answer to Has any serious project been written in a non-English-based programming language?)提到西門子(德)/愛立信(瑞典)內部有儘量用母語命名的 C/C++專案. 以及布拉格看到的一本程式設計書中的示例程式碼也是用母語命名.
開源專案中也有不少. 這是一位臺灣開發者用Python開發的自然語言處理工具: 臺灣言語工具 專案成型於2013年, 程式碼目測數萬行.
最初在程式語言中新增支援 Unicode 的功能, 也應該有各個非英語母語國家/地區開發者的推動力量.
2018-07-18更新
中文比英文更難以理解
答: 比如假設中國人最先開發電腦和設計程式語言，那麼各種程式語言會使用漢字嗎？. 問題是, 無論從什麼角度說, 中文也是中國人的母語, 而母語優勢已經由前面的"沒有好處"一節說明. 退一萬步說, 即使這個命題成立, 也只能用來說明中國人用中文作為母語導致了理解效率落後. 而不能說明中文命名不適合於國人.
2018-07-22更新
“我們在用C++，Java，Python程式設計，不是在用英文程式設計”
答: 這是很常見的一個說法, 比如這裡. 之前的"沒有好處"和"程式語言本身和英文語法無關"等節已經闡述了命名和程式語言語法和自然語言直接的關係. 如果還不夠說服力, 也許可以看看國外非英語母語的開發者. Linus(Linux作者)的回答(原文在Interview: Linus without Linux): “我一直用英文程式設計”. 而且他還提到程式語言都是基於英文的. 節選如下:
Question: What language did you use in comments to Linux while you were a student?
Torvalds: English. I’ve always programmed in English. All the books were in English, and the programming-languages tend to be somewhat English-based too (i.e. “while (x) { … }”).