---
title: Go 里 receiver name 不建议写成 this，是在强调类型身份
date: '2016-01-20 09:00:28'
draft: false
summary: 这不只是命名风格问题，背后其实是在避免把方法接收者抽象成一个模糊的统一对象。
slug: golint-receiver-name-should-reflect-type-identity
syndication:
- platform: Weibo
  url: https://weibo.com/1648815335/DdXT6uLd0
tags:
- golang
- coding-style
- lint
topics:
- software-engineering
type: post
---

第一次看到 `golint` 这个规则时，我的直觉其实和很多从 `Java` 过来的人一样：

> 为什么 receiver 不能直接叫 `this`？

毕竟 `this` 这件事很省脑子。你不用为每个 `struct` 再想一个变量名，统一写法，看起来也整齐。

但后来我越来越觉得，`golint` 这个约束虽然有点烦，本质上还是有它自己的语言立场。

`Go` 并不太鼓励把方法接收者理解成传统面向对象语境里的那个“对象自我”。它的方法更像是“对某个具体类型值的操作”，而不是围绕一个统一的对象语义展开。

所以 receiver name 被要求“reflect its identity”，意思其实不是非要大家搞花哨命名，而是要让接收者名字和类型本身建立稳定映射。

比如：

- `Server` 用 `s`
- `Client` 用 `c`
- `Request` 用 `r`

这样读代码时，方法体里的接收者并不是一个抽象的 `this`，而是这个具体类型在当前上下文里的缩写。

这件事带来的一个好处是：代码在跨文件、跨包阅读时，类型感会更强。尤其在 `Go` 这种接口组合很多、结构体又比较轻量的语言里，接收者如果都写成 `this`，其实不利于快速建立“当前到底是谁在做事”的直觉。

当然，从纯效率角度说，我还是能理解很多人会嫌麻烦。因为这个规则本身不会改变程序行为，更多是在统一团队阅读体验。

所以我的结论比较简单：

- 如果是 `Go` 项目，就按 `Go` 社区的约定来，别硬拿其他语言的习惯对抗。
- 如果只是个人审美上更喜欢 `this`，也不是完全不能理解，但最好别跟 lint 工具和团队规范拧着来。

这种事最终不在于谁绝对正确，而在于语言社区到底想把代码引向什么样的阅读方式。`Go` 在这里强调的，显然不是“对象感”，而是“类型身份感”。