並非所有人都同意作者的觀點。Go 語言的部分開發者主張名字應該很短，常常只是單一字母。

Go 的論點#

Andrew Gerrand 在 Go 命名簡報中說：「長名稱會遮蔽程式碼在做什麼。」

他舉出兩個版本：

短名版本#

func RuneCount(b []byte) int {
    i, n := 0, 0
    for i < len(b) {
        if b[i] < RuneSelf {
            i++
        } else {
            _, size := DecodeRune(b[i:])
            i += size
        }
        n++
    }
    return n
}

長名版本#

func RuneCount(buffer []byte) int {
    index, count := 0, 0
    for index < len(buffer) {
        if buffer[index] < RuneSelf {
            index++
        } else {
            _, size := DecodeRune(buffer[index:])
            index += size
        }
        count++
    }
    return count
}

作者的反論#

作者並不覺得長名版本比短名版本難讀。

• count 比 n 提供了更好的行為線索
• 看短名版時，作者得讀程式碼才能搞清楚 n 是什麼；長名版本就不必

但若 n 在整個系統中始終只代表「count」（且不代表別的） → 對熟悉這套慣例的人也許清楚。

Go 文化的潛在風險#

Go 文化鼓勵「用同一個短名表達多種東西」：

• ch：character 或 channel
• d：data、difference 或 distance

這正是 Sprite block bug 的同類陷阱——曖昧名容易引發錯誤。

可讀性由讀者決定#

可讀性必須由讀者判斷，不是作者。

• 你寫短名，讀的人覺得好懂 → 那就 OK
• 開始接到「程式碼很 cryptic」的抱怨 → 該考慮長名
• 反過來：作者也說，若有人抱怨他的長名變數讓程式碼難讀，他會考慮改短

（網路搜尋 “go language short names” 能看到不少這類抱怨。）

一個雙方都同意的原則#

Gerrand 提的這條，作者完全同意：

「名字宣告與其使用之間距離越大，名字應該越長。」

短迴圈用 i、j 是這條原則的應用。