【问题标题】:golang variable naming convention across packages跨包的golang变量命名约定
【发布时间】:2018-06-20 13:14:02
【问题描述】:

最近我开始学习 go-ethereum,这是我第一次使用 golang。 C++ 是我的主要语言,由于 go-ethereum 项目中的变量名,我有点困惑。

core/state/managed_state.go:25:type account struct {

core/state/state_object.go:98:type Account struct {

state包中同时存在“account”和“Account”两种类型,看起来很奇怪。

我检查了Naming convention for similar Golang variables,但它看起来仍然很糟糕。

我发现他们在不同的包中使用了很多“节点”结构。当然,它们确实有不同的目的和结构。

这些命名在 golang 中是约定俗成的吗? 如果您对 golang 中的命名约定有任何好的参考(例如开源项目或书籍),您能说出其中的一些吗?将不胜感激。

【问题讨论】:

标签: go naming-conventions


【解决方案1】:

state包中同时存在“account”和“Account”两种类型,看起来很奇怪。

在语言规范中这两个名称之间存在显着差异。

来自Go Language Specification

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

  1. 标识符名称的第一个字符是 Unicode 大写 字母(Unicode 类“Lu”);和
  2. 标识符在 包块或者它是一个字段名或方法名。

不导出所有其他标识符。

所以,仔细看看 go-ethereum 代码库,以下是我的观察:

当您查看 the generated documentation 时,我认为实现选择更有意义。

特别是Account type is front and center,详细说明了软件包消费者感兴趣的数据结构。

当您查看the documentation for the ManageState struct 时,故意未记录未导出的字段。这是因为它们是内部细节,不会影响导出的界面,并且可以轻松更改而不会影响包的用户。


关于命名建议,请参阅Names section in Effective Go

【讨论】:

  • 感谢您的回答@chuckx,但我知道第一个字符决定了可导出性,但它似乎仍然令人困惑。我想问的是,这种命名方式在golang中是不是很正常。如果您看一下,您会发现它们之间的差异。如果它们有不同的名称,例如 accountSomething1 和 AccountSomething2,那不是更好吗?
  • 通过对代码库的一些观察更新了答案。
  • “难道不是更好吗”是一个意见问题(对于 SO 来说是 OT),也是项目维护者的问题,而不是整个社区的问题。如果您对特定项目的设计决策有任何疑问,请询问做出这些决策的人。
猜你喜欢
  • 2016-12-15
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2010-09-19
  • 1970-01-01
  • 2023-01-26
  • 2013-12-31
相关资源
最近更新 更多