一、話題背景

在軟件開發領域，代碼的可讀性是一個不容忽視的問題。一個常見的挑戰是變量命名的規范性。不規范的定義和隨意的命名習慣常常使得研發人員難以理解變量的具體含義及其用途。

那當研發人員沒有寫注釋時，這就要求在寫變量名稱的時候，需要讓其他研發同學看得懂這是什么意思，它的用途是什么。如果看不懂的情況下，亂猜的場景下，就可能導致傳錯參數，出現bug。

那么就有同事提出了這幾種變量命名選項：

• 方式一：英文直譯，直觀，但是一旦遇到復雜的定義時，命名的名稱就可能很長了。
• 方式二：一定程度的縮寫，大概率能猜測出來，感覺不怎么好看。
• 方式三：完整縮寫，如果不寫注解，完全看不出意思；大部分代碼都不寫注解的。

所以面對這些命名選項，大家認為哪種方式更為合適，或者是否有其他更好的命名方式呢？

二、鵝廠工程師的看法

1.

 miey-S1安全規劃中心應用研究員 

駱駝命名法挺好使的，混合使用 拼音/英文單詞/單詞縮寫 構成變量和函數的名字。StudentNum、student_num，如果不是 num、cnt、idx、len、avg、obj、pkg、func、info 等等耳聞能詳的縮寫，就沒必要強行縮寫了

另外，這個方式三....真的有被笑到

2.

lakhdar-TEG應用開發工程師

studentNum，太長的話用縮寫+注釋。

3.

 chuan-CDG應用開發工程師 

num 和 number 是一個有二義性的詞匯，不要使用。 它既可以表示總數，也可以表示序號。

有人會認為 studentNumber 天然是學生數量的意思，但是通常 idNumber 就不是id數量的意思，而是身份證號。

那么 carNumber是汽車數量的意思，還是汽車號碼的意思呢？這就讓代碼復雜化了。

studentCount 是一個一般好的名字，studentCnt是一個更好的名字。

All you need is Code Complete（《代碼大全》）

4.

 krisjc-TEG運營開發工程師 

studentCount。

我個人覺得變量名不怕你起得長，就怕你起得短。不然后來人看你的代碼一臉懵，可讀性才是第一位的。

“我們要規避過于罕見或者根本不常用的單詞，甚至是自己創造的詞語，那更是禁忌，畢竟代碼是給人讀的，而不是什么過于抽象的藝術作品?！?/p>

5.

 kernbin-WXG客戶端開發工程師

視情況而定吧，如果上下文給足了信息，比如這是一個局部變量，在一個很短的名為 CountNumberOfStudent 的小函數里，那么我覺得可以短一些，二或者三都可以，因為信息足夠了。

如果這是個全局變量（先不談全局變量是否要加 g_ 之類的前綴）或者某個很復雜很大的函數里，那么我覺得名字應該足夠長足夠完整。因為在這個變量用到的上下文中信息不一定充足。

6.

 n-TEG后臺開發工程師

除非是業界習俗或公認，一個單詞截一部分的應該排斥。

以下是幾個壞例子：

• stNum
• stuNum
• studNum
• studeNum
• studenNum

7.

 langdon-IEG運營開發工程師

變量名長度和作用域正相關?？梢詤⒖肌洞a整潔之道》clean code。

另外， IDE+AI時代，似乎沒有必要用numStuds這種不節約幾個字母，還容易造成歧義的縮寫，除非stud的寫法取得局部共識。

8.

 kairee-IEG UI開發工程師

studentCount, studentNumber。

為什么要在意變量名稱長？難道是用紙和筆寫代碼嗎？

9.

kael-TEG運營開發工程師

變量取名實際上服務于代碼閱讀人。這個代碼閱讀人可以是你是你的團隊，也可以是只有你自己。

通常來說，為了保障團隊的閱讀，應使用描述足夠準確和無歧義的名字。

如果存在某段代碼，后續永遠不用修改和維護，或者只用運行一次，那么名稱的長短就不那么重要了。例如臨時編寫的腳本，用完就刪的那種。

還有一種極端的情形，在類似ACM的競賽中，通常就會把名字取成和題目描述中一致，包括x,y,z,n,m,q,p這種。一方面是能夠在爭分奪秒的比賽中快速打碼，另一方面是與原題中變量語義保持一致，減少反復讀題的變量轉換理解的開銷，本身也可以增加閱讀效率。