golang 代码里有很多单字母的变量是因为变量冗长程度与变量声明位置到变量使用位置的距离成正比。也就是越局部使用的变量就越短，因为你一眼就能看到上下文，短名字不会造成迷惑。
一、为什么 golang 代码里有很多单字母的变量
golang 代码里有很多单字母的变量是因为变量冗长程度与变量声明位置到变量使用位置的距离成正比。也就是越局部使用的变量就越短，因为你一眼就能看到上下文，短名字不会造成迷惑。
这也算是贝尔实验室的UNIX团队流毒，你如果去看早期UNIX代码（比如那本 UNIX v6源码解读）也是这个风格。The UNIX haters handbook对这风格的真实原因有解释，主要就是早年电传打字机需要很大的按键力量，像Java这样命名手指能断掉。
receiver 在很多其他语言里面，比如 C++/Java 里对应的是 this 或者 self，甚至是可以不写的。而在 Go 里，receiver 的名字是在一个视觉上很容易找的地方：它是整个函数定义的名列前茅行，顶格的一行（另一个顶格的行是最后 close 的反大括号，一般就没有别的行顶格了）即使是较长的函数也不影响理解，反倒让代码更加简洁易读。因此，用一个单字母来表示 receiver 比 this 和 self 这样可以省略的长单词好。
延伸阅读：
二、golang基于 goroutines 和 channels 的简单并发编程
Goroutines 可能是 Go 的优异特性了。它们是轻量级的计算线程，与操作系统线程截然不同。
当 Go 程序执行看似阻塞 I/O 的操作时，实际上 Go 运行时挂起了 goroutine ,当一个事件指示某个结果可用时恢复它。与此同时，其他的 goroutines 已被安排执行。因此在同步编程模型下，我们具有了异步编程的可伸缩性优势。
Goroutines 也是轻量级的:它们的堆栈 随需求增长和收缩，这意味着有 100 个甚至 1000 个 goroutines 都不是问题。
我以前的应用程序中有一个 goroutine 漏洞:这些 goroutines 结束之前正在等待一个 channel 关闭，而这个 channel 永远不会关闭(一个常见的死锁问题)。这个进程毫无任何理由吃掉了 90 % 的 CPU ，而检查 expvars 显示有 600 k 空闲的 goroutines! 我猜测 goroutine 调度程序占用了 CPU。
当然，像 Akka 这样的 Actor 系统可以轻松 处理数百万的 Actors，部分原因是 actors 没有堆栈，但是他们远没有像 goroutines 那样简单地编写大量并发的请求/响应应用程序（即 http APIs）。
channel 是 goroutines 的通信方式:它们提供了一个便利的编程模型，可以在 goroutines 之间发送和接收数据，而不必依赖脆弱的低级别同步基本体。channels 有它们自己的一套 用法 模式。
但是，channels 必须仔细考虑，因为错误大小的 channels (默认情况下没有缓冲) 会导致死锁。
