Golang命名规范新探讨

Golang命名规范新探讨 大家好，

我在思考 Go 语言的命名语法。众所周知，首字母的大小写决定了函数和变量的可见性。

由于 Go 语言没有严格的命名标准，我个人经常使用蛇形命名法，这纯属个人偏好。以前用 Java 编程时，我喜欢驼峰/帕斯卡命名法，但那时首字母大小写有严格的规定。如果在 Go 中使用驼峰命名法，我通常会为公开函数写 GetStuff()，而不是像在 Java 中那样写 getStuff()。个人而言，GetStuff() 看起来有点伤眼睛。

在 Python 中，我们可以轻松地实现一个公开函数 get_stuff() 或一个私有函数 _get_stuff()，虽然不算漂亮，但可以接受。

言归正传：在 Go 语言中，如果我选择使用蛇形命名法，那么私有函数看起来会像 get_stuff()。相应地，公开函数会被命名为 Get_stuff()，这看起来像一条大头的蛇。这让我想到：我们是不是应该称这种命名为“眼镜蛇命名法”？

我不知道这个话题有多大用处，但“眼镜蛇命名法”让我心情很好 😁。

祝大家一切顺利！


更多关于Golang命名规范新探讨的实战教程也可以访问 https://www.itying.com/category-94-b0.html

4 回复

据我所知，虽然没有官方的标准，但惯用的代码会使用驼峰命名法（例如，可以看看标准库）。

在你的代码中，你可以做任何你想做的事（没人会阻止你），但我倾向于避免使用那些偏离惯例的包，没有其他原因，只是因为作者很可能对标准库不熟悉，因此也可能不太精通 Go 语言。

更多关于Golang命名规范新探讨的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


命名确实很难 😄

但就我个人而言，我对 Go 语言的这种方式没有额外的问题。 我经常使用命名导入，在这种情况下会是：

package.GetStuff()

而我自己处理的方式是为结构体名称加上一个 T 后缀。

所以，与其使用 type Stuff struct {}，我会用 StuffT struct，并且在前端的 TypeScript 中也遵循同样的规则。这样我总能清楚地区分类型定义和实际的结构体。

基于使用多种其他语言的经验，我确实觉得 Go 语言中“首字母大写表示公开”的约定有点过于讨巧了。对于我必须创建和使用的名称所带来的视觉印象，我也感到有些困扰。

Go 本可以有一个“public”和“private”限定符，这只会使（解析）名称声明的那一处变得复杂。它并不会使包的开发者工作复杂化，因为他们已经需要做出可见性决定了。

当使用导入的名称时，所有当前可见的名称都具有那个首字母大写字符，格式为 <package>.<大写首字母><名称其余部分>。这对所有使用者来说都只是冗余的工作。

为什么不扩展 Go 值得称赞的命名自由，允许公开名称也可以使用首字母小写呢？

在Go语言中，命名规范确实是一个值得探讨的话题。虽然Go官方没有像Java那样严格的命名标准，但社区已经形成了一些约定俗成的实践。

首先，关于可见性规则：在Go中，标识符的首字母大小写决定了其包外可见性。大写字母开头的标识符是公开的（exported），小写字母开头的标识符是私有的（unexported）。这是Go语言设计的一部分，无法更改。

关于命名风格，Go社区强烈推荐使用驼峰命名法（camelCase），而不是蛇形命名法（snake_case）。这是由Go官方代码库和标准库确立的惯例。例如：

// 公开函数使用帕斯卡命名法（首字母大写）
func GetStuff() {
    // 实现
}

// 私有函数使用驼峰命名法（首字母小写）
func getStuff() {
    // 实现
}

// 公开变量
var ImportantValue int

// 私有变量
var internalValue string

对于你提到的"眼镜蛇命名法"（Get_stuff()），这种混合风格在Go社区中是不被推荐的，因为它违反了Go的命名惯例。Go的命名应该保持一致性，要么全部使用驼峰命名法，遵循首字母大小写决定可见性的规则。

如果你真的非常喜欢蛇形命名法，可以考虑以下方式：

// 私有函数使用蛇形命名法
func get_stuff() {
    // 实现
}

// 公开函数也使用蛇形命名法（但首字母大写）
func Get_stuff() {
    // 实现 - 但这不符合Go惯例
}

但需要注意的是，这种风格可能会让其他Go开发者感到困惑，也不利于代码的一致性。大多数Go工具链（如gofmt、golint等）和IDE都是基于驼峰命名法的惯例来设计的。

在实际项目中，建议遵循Go社区的命名惯例，这样可以：

  1. 保持代码一致性
  2. 便于其他开发者理解
  3. 与Go工具链更好地集成
  4. 符合大多数Go项目的代码审查标准

虽然"眼镜蛇命名法"这个想法很有趣，但在实际开发中，还是建议遵循Go社区的命名惯例，使用驼峰命名法并利用首字母大小写来控制可见性。

回到顶部