Go 的 const 命名约定
我正在尝试确定 Golang 中 const 的名称是否存在命名约定。
我个人倾向于遵循 C 风格并以大写形式编写它们，但我在此页面 http://golang.org/doc/effective_go.html 上没有找到任何似乎列出该语言的一些命名约定的内容。
FOO_BAR_BAZ 样式编写常量，但不幸的是，这会影响常量的可见性，而且并不常见。即使我不喜欢它，我也只能忍气吞声接受这个约定。
标准库使用驼峰式，所以我建议你也这样做。第一个字母是大写还是小写取决于您是否要导出常量。
几个例子：
md5.BlockSize
os.O_RDONLY 是一个例外，因为它是直接从 POSIX 借来的。
os.PathSeparator
Go Code Review Comments 该页面收集了 Go 代码评审过程中的常见评论，以便一个详细的解释可以简写参考。这是一份常见错误的清单，而不是风格指南。您可以将其视为对 http://golang.org/doc/effective_go.html 的补充。混合大写请参阅 http://golang.org/doc/effective_go.html#mixed-caps。即使它违反了其他语言的约定，这也适用。例如，未导出的常量是 maxLength 而不是 MaxLength 或 MAX_LENGTH。
有效的 Go MixedCaps 最后，Go 中的约定是使用 MixedCaps 或 mixedCaps 而不是下划线来编写多字名称。
Go 编程语言规范导出的标识符 可以导出一个标识符以允许从另一个包访问它。如果满足以下两种情况，则导出标识符： 标识符名称的第一个字符是 Unicode 大写字母（Unicode 类“Lu”）；并且标识符是在包块中声明的，或者是字段名或方法名。不会导出所有其他标识符。
使用混合大写。
具体例子。请注意，在常量中声明类型（相关时）可能对编译器有所帮助。
// Only visible to the local file
const localFileConstant string = "Constant Value with limited scope"
// Exportable constant
const GlobalConstant string = "Everyone can use this"
const元素暴露给其他包也很重要。如果您使用UpperCamelCase或ALL_CAPS，您将把它导出到您的包之外。出于这个原因，对于私有 const 变量，我坚持使用lowerCamelCase，并且我记得从与 Go 项目相对接近的人那里（或者甚至可能在官方文档中——我忘记了在哪里）读过这个建议。HTTPID而不是HTTP_ID。我的代码中有LED_A、LED_B等，现在必须更改为LEDA、LEDB等以遵循约定，这样 lint 就不会抱怨。我认为后者的可读性较差，尤其是当您加入两个较长的首字母缩略词时。