為什麼 golang 代碼里有很多單字母的變數？

標準庫和第三方開源包里到處都是單字母變數，比如
connection -&> c
client -&> c
pool -&> p
list -&> l

option -&> o
session -&> s
server -&> s
不只是 receiver ，局部變數／成員變數也有這種情況，比如 golang/go
這個標準庫里 teeReader 就有 r, w 兩個成員變數，LimitedReader 有 R, N 兩個成員變數，ReadAt() 的入參 p 返回值是 n
這種命名不是早就被批判 n 年了嗎，怎麼在 golang 里又死灰復燃了。

Brian W. Kernighan 和 Rob Pike 在 The Practice of Programing 書（主要用 C 語言講述）提出的變數命名原則：變數冗長程度與變數聲明位置到變數使用位置的距離成正比。也就是越局部使用的變數就越短，因為你一眼就能看到上下文，短名字不會造成迷惑。

這也算是貝爾實驗室的UNIX團隊流毒，你如果去看早期UNIX代碼（比如那本 UNIX v6源碼解讀）也是這個風格。The UNIX haters handbook對這風格的真實原因有解釋，主要就是早年電傳打字機需要很大的按鍵力量，像Java這樣命名手指能斷掉。

這東西是玄學，你完全可以說什麼單字元變數有多簡潔，在上下文明確的情況下可用；也可以說Java這種長的變數名提高可讀性；

具體用什麼，完全取決於創建這門語言的人、寫標準庫的人的喜好，沒有必要糾結，團隊統一就行了

第一呢，單字母變數命名也是有表達力，有很多約定俗成的單字母變數一直都在廣泛使用。

下面這個是Java 8中ArrayList的實現。用a來代表array，c來代表collection，在這樣一個意義明確的短方法里，很難產生的歧義，也不降低可讀性。那為什麼一定要個很長的名字才好呢？

當然要是這個方法有50行長，方法後半段也要用這個a，你要是寫Object[] array來代替Object[] a，我覺得也是值得提倡的。而且你看他這個size也沒有用s來代替，因為size是一個類成員變數，作用域更大，如果在代碼里突然出現一個s是很奇怪的。

public boolean addAll(Collection& extends E&> c) { Object[] a = c.toArray(); int numNew = a.length; ensureCapacityInternal(size + numNew); // Increments modCount System.arraycopy(a, 0, elementData, size, numNew); size += numNew; return numNew != 0; }

第二呢，這事真的要看上下文，比如說如果我們這裡還有另外一個array，那你用a或者array都不太合適，你可以用裡面的內容來命名，比如說users, userArray, intArray，或者職責來命名results, resultArray之類的也是好的命名。

看得懂就行取決於作者水平

貌似題主舉的例子都是 receiver 的例子。receiver 在很多其他語言裡面，比如 C++/Java 里對應的是 this 或者 self，甚至是可以不寫的。而在 Go 里，receiver 的名字是在一個視覺上很容易找的地方：它是整個函數定義的第一行，頂格的一行（另一個頂格的行是最後 close 的反大括弧，一般就沒有別的行頂格了）即使是較長的函數也不影響理解，反倒讓代碼更加簡潔易讀。因此，用一個單字母來表示 receiver 比 this 和 self 這樣可以省略的長單詞好。

謝邀。

在語意不受干擾，上下文足夠清晰的情況下，保留短名字與長名字沒有太大的區別。

以上是友善的回答，下面是我的回答：

還不是因為官方庫里的怪癖被濫用還強製成為了信條一樣的東西，簡直讓人頭禿。

有自信，能夠命名的清晰不奇異。

相信你足夠默契，給個眼神就好。

挺好的啊，你看得懂就好，反而是java中哪些二十個字母的變數，你真的覺得好么？特別再鏈式表達式，你確定看著不眼花么？

定義變數是程序員第一大難題，超過np問題

命名要求:簡單明了直觀準確，準確在最後，一個c可以明白，為什麼要寫coonectionPoolForBusiness？

Go對命名的要求太苛刻，大寫開頭的總是被導出，不導出的只能用小寫。

假如你需要定義一個不導出的結構對象，你只能用縮寫，因為用小寫開頭的名字已經被類型名佔用了。

另一個問題是沒有enum，一樣會造成命名困難。