2015-11-22 17:22


  • IT行业问题
  • 计算机技术
  • it技术
  • 编程语言问答
  • 互联网问答

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:


Now, this advice doesn't seem to consistent as the stdlib itself violates this multiple times. enter image description here

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?

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答


  • doukefu1361 doukefu1361 6年前

    [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.


    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:


    It feels very ad-hoc, and hard to recall.

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

    点赞 评论 复制链接分享
  • dsfs64664 dsfs64664 6年前

    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.

    点赞 评论 复制链接分享
  • dongluolie3487 dongluolie3487 6年前

    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.

    点赞 评论 复制链接分享