Idiomatic way of naming Getters in Go

huangapple go评论85阅读模式
英文:

Idiomatic way of naming Getters in Go

问题

《Effective Go》对于getter的命名给出了以下建议:

Go语言不提供自动支持getter和setter。自己提供getter和setter没有问题,而且通常是合适的,但在getter的名称中加入Get既不符合惯例,也不是必要的。如果你有一个名为owner的字段(小写,未导出),getter方法应该被称为Owner(大写,导出),而不是GetOwner。使用大写名称来导出提供了区分字段和方法的钩子。如果需要,setter函数可能被称为SetOwner。这两个名称在实践中都很好读取:

来源:https://golang.org/doc/effective_go.html#Getters

现在,这个建议似乎不一致,因为标准库本身多次违反了这个建议。
Idiomatic way of naming Getters in Go

如上面的截图所示,有多个方法使用了GetX的命名约定,而这在《Effective Go》指南中是不建议的。

所以问题是,《Effective Go》中给出的建议是错误的,还是这些方法的命名是错误的,并且将在将来的版本中修复?

英文:

The Effective go has following advice on naming of getters:

> Go doesn't provide automatic support for getters and setters. There's
> nothing wrong with providing getters and setters yourself, and it's
> often appropriate to do so, but it's neither idiomatic nor necessary
> to put Get into the getter's name. If you have a field called owner
> (lower case, unexported), the getter method should be called Owner
> (upper case, exported), not GetOwner. The use of upper-case names for
> export provides the hook to discriminate the field from the method. A
> setter function, if needed, will likely be called SetOwner. Both names
> read well in practice:

Source: https://golang.org/doc/effective_go.html#Getters

Now, this advice doesn't seem to consistent as the stdlib itself violates this multiple times.
Idiomatic way of naming Getters in Go

As you can see in above screenshot, there are multiple methods which use GetX naming convention which is advised against in the effective go guide.

So the question is is the advice given in guide wrong or these methods are named wrongly & would be fixed in future versions?

答案1

得分: 9

这些名称与 Go 的命名方式不一致。Go 的创始人之一 Rob Pike 在关于 OS 包中的这些名称的讨论中说道:

> 这里确实存在一些不一致之处,但这是关键点。应该是 Stdout 而不是 StdOut,因为该名称来自底层系统。同样,应该是 Fprintf 而不是 FPrintf 或 FPrintF,因为这是一个非常熟悉的名称。这些名称是引入到 Go 中的,而不是在 Go 中创建的,而首字母大写是入场费。

这些名称在未来的 Go 版本中不会被更改。

英文:

These names are not consistent with Go naming by design. Rob Pike, one of the Go creators, says this about the names in the OS package:

> There are inconsistencies but this is the key point. It should be Stdout not StdOut, because that name is coming from the underlying system. Similarly it's Fprintf not FPrintf or FPrintF because that is a very familiar name. These names are coming into Go, not being created there, and the initial cap is the admission fee.

The names will not be changed in a future version of Go.

答案2

得分: 5

“getters”一词指的是在“structs”上的方法,它允许您读取该结构上的(通常是未导出的)字段的值。您指向的函数是顶级函数,它允许您从操作系统中读取值。这个惯用规则与这种情况无关。

英文:

The term "getters" refers to methods on structs that allow you to read values of (often unexported) fields on that struct. The functions you're pointing to are top-level functions which allow you to read values from the OS. That idiomatic rule is not relevant to this case.

答案3

得分: 3

> [go-nuts] 函数命名大小写不一致
>
> 在我们还没有弄清楚命名规范应该是什么之前,很多全小写的名称都是在选择的。我们采用的规则是,在ossyscall包中的入口点,它们是根据C语言中的等效项命名的,只有一个大写字母开头,以避免需要决定缩写中的内部大写字母位置,比如geteuidgetwdchdir。像Readdirnames这样的名称,它们是实际的单词,可能值得重新考虑。
>
> Russ


> os: 函数命名大小写不一致 #1187
>
> 有关“os”包中函数命名大小写的规则吗?浏览一下,似乎很难记住一个给定的函数应该被称为LikeThat还是Likethat
>
> 例如:
>
>
> Mkdir
> MkdirAll
> TempDir
> Getenv
> ForkExec
> Readlink
> ReadAt
> Readdir
>
>
> 这感觉非常临时,很难记住。

这是一个已知的问题。目前没有计划解决。

英文:

> [go-nuts] FunctionName caseinconsistencies
>
> A lot of the all lowercase names were chosen before we had really
> figured out what the naming conventions should be. The rule we
> adopted, which might be worth revisiting later, was that entry points
> in package os or syscall, which are named after equivalents in C, just
> had a single capital at the beginning, to avoid needing to decide
> where the internal capitalizations are in abbreviations like geteuid
> or getwd or chdir. Names like Readdirnames, which are actual words,
> might be worth revisiting at some point.
>
> Russ


> os: inconsistent casing in names #1187
>
> Is there any sort of rule about the casing of functions used in the
> "os" package? Looking through, it doesn't sound like it's very easy
> to recall whether a given function should be called LikeThat or
> Likethat.
>
> For instance:
>
>
> Mkdir
> MkdirAll
> TempDir
> Getenv
> ForkExec
> Readlink
> ReadAt
> Readdir
>
>
> It feels very ad-hoc, and hard to recall.

It's a known issue. It's unplanned.

huangapple
  • 本文由 发表于 2015年11月23日 01:22:08
  • 转载请务必保留本文链接:https://go.coder-hub.com/33857756.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定