Golang标识符中的下划线使用探讨

Golang标识符中的下划线使用探讨 我正在开发我的第一个 Go generate 包，它生成一个类似于 stringer 工具的 (type)_string.go 文件的 Go 文件。我目前还处于调试阶段，所以不确定默认文件名应该是什么。我决定创建一个常量 pkgsyms_go = "pkgsyms.go"，并在几个需要的地方引用这个常量，这样如果我更改它，在我修复所有名称使其保持一致之前，编译器会报错。

当 VS Code 对我的代码进行 lint 检查时，我收到了这个警告：

don't use underscores in Go names; const pkgsyms_go should be pkgsymsGo

我明白这个警告的含义，并且不打算与 linter 对抗；我会直接将其重命名为 pkgsymsGo。我想知道的是这个警告背后的解释。如果没有人知道原因，有没有人知道我自己该如何找出原因？

我查阅了语言规范，看到可以在数字之间使用下划线以使数字更易读，但我不知道这是否是它们不鼓励在标识符中使用下划线的原因。我也尝试过搜索原因，但只找到了关于单个下划线（"_"）用途的解释。

有没有人知道为什么在标识符中使用下划线会触发 linter 警告？

附言：我实际上不知道我运行的是什么 linter，或者如何找出它是什么……我通常只是在纯文本编辑器中编写代码，然后逐行处理编译器的警告/错误，直到代码正常工作。我以前用过 VS Code，我喜欢它更频繁的错误和警告消息更新，但我不知道如何找出产生这些信息的魔法是什么！


更多关于Golang标识符中的下划线使用探讨的实战教程也可以访问 https://www.itying.com/category-94-b0.html

2 回复

最后，Go 语言中的惯例是使用 MixedCaps 或 mixedCaps 而不是下划线来书写多词名称。

请参阅 Effective Go - The Go Programming Language

引言说明了格式为何重要：

了解 Go 编程中已建立的惯例也很重要，例如命名、格式、程序结构等，这样你编写的程序才能让其他 Go 程序员易于理解。

更多关于Golang标识符中的下划线使用探讨的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


在 Go 语言中，标识符命名规范遵循驼峰式命名法（camelCase），这是 Go 社区广泛接受的约定。golint（或 gofmt 等工具）会检查代码风格，当遇到下划线命名的标识符（如 pkgsyms_go）时，会提示警告。这并非语言层面的限制，而是为了保持代码风格的一致性。

示例：

// 不推荐（触发 linter 警告）
const pkgsyms_go = "pkgsyms.go"

// 推荐（驼峰式命名）
const pkgsymsGo = "pkgsyms.go"

原因分析：

  1. 社区约定：Go 官方文档和开源项目普遍使用驼峰命名，下划线通常仅用于特殊场景（如忽略变量的 _）。
  2. 可读性：驼峰命名在 Go 生态中更易读，且与标准库风格统一（如 json.Unmarshal）。
  3. 工具链支持：golint 等工具会依据 Go Code Review Comments 中的规范进行检查。

如何查看当前 linter： 在 VS Code 中，默认使用 gopls（Go 语言服务器）进行静态分析。可通过以下步骤确认：

  1. 打开 VS Code 设置（Ctrl+,）。
  2. 搜索 Go: Lint Tool，查看配置的 linter（常见为 staticcheck 或 golangci-lint）。

代码生成场景的例外： 对于生成的代码（如 stringer 工具生成的文件），下划线命名可能被接受，因为生成的文件通常不需要人工维护。但手动编写的代码仍建议遵循驼峰命名。

示例（生成文件中的下划线使用）：

// 生成的文件可能包含下划线（如自动生成的类型名）
type myType int

// 生成的文件名常带下划线（如 type_string.go）
// 但手动定义的常量仍应使用驼峰命名
const generatedFileName = "type_string.go"

若需临时忽略该警告，可在常量定义前添加 //nolint 注释（需 linter 支持）：

//nolint
const pkgsyms_go = "pkgsyms.go"

但建议优先遵循命名规范。

回到顶部