Go 的 const 命名约定答案

【问题标题】：Go naming conventions for constGo 的 const 命名约定
【发布时间】：2014-05-06 12:03:48
【问题描述】：

我正在尝试确定 Golang 中 const 的名称是否存在命名约定。

我个人倾向于遵循 C 风格并将它们写成大写，但我在此页面上没有找到任何内容 http://golang.org/doc/effective_go.html 似乎列出了该语言的一些命名约定。

【问题讨论】：

为了便于阅读，我很想以FOO_BAR_BAZ 样式编写常量，但不幸的是，这会影响常量的可见性，而且并不常见。即使我不喜欢它，我也只能忍气吞声接受约定。

标签： go constants naming-conventions

【解决方案1】：

标准库使用驼峰式，所以我建议你也这样做。第一个字母是大写还是小写取决于您是否要导出常量。

几个例子：

md5.BlockSize
os.O_RDONLY 是一个例外，因为它是直接从 POSIX 借来的。
os.PathSeparator

【讨论】：

确定您是否希望const 元素暴露给其他包也很重要。如果您使用UpperCamelCase 或ALL_CAPS，您将把它导出到您的包之外。出于这个原因，对于私有 const 变量，我坚持使用 lowerCamelCase，我记得从与 Go 项目（或者甚至可能在官方文档中——我忘了在哪里）相对接近的人那里读过这个建议。
帕斯卡案
我同意这是 Go 中的正确方法，但是在两个单词大写并且不允许使用下划线的情况下，它会更难阅读，例如 HTTPID 而不是 @987654329 @。我的代码中有LED_A、LED_B 等，现在必须更改为LEDA、LEDB 等以遵循约定，这样lint 就不会抱怨。我认为后者的可读性较差，尤其是当您加入两个较长的首字母缩略词时。
首先我听说过“大写”驼峰式大小写，但它可能比帕斯卡大小写更好，后者是 VariablesLikeThis 的历史名称

【解决方案2】：

具体例子。请注意，在常量中声明类型（如果相关）可能对编译器有所帮助。

// Only visible to the local file
const localFileConstant string = "Constant Value with limited scope"

// Exportable constant
const GlobalConstant string = "Everyone can use this"

【讨论】：

【解决方案3】：

Go Code Review Comments

本页收集了 Go 代码评审过程中常见的 cmets，所以一个详细的解释可以用简写来引用。这是一份常见错误的清单，而不是风格指南。

您可以将此视为对 http://golang.org/doc/effective_go.html。

Mixed Caps

见http://golang.org/doc/effective_go.html#mixed-caps。这适用即使它打破了其他语言的惯例。例如一个未导出的常量是 maxLength 而不是 MaxLength 或 MAX_LENGTH。

Effective Go

MixedCaps

最后，Go 中的约定是使用 MixedCaps 或 mixedCaps 而不是比下划线写多字名称。

The Go Programming Language Specification

Exported identifiers

可以导出一个标识符以允许另一个标识符访问它包裹。如果两者都导出一个标识符：

标识符名称的第一个字符是 Unicode 大写字母（Unicode 类“Lu”）；和

标识符在包块中声明或者是字段名或方法名。

不导出所有其他标识符。

使用混合大写。

【讨论】：