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.
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?
[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
orsyscall
, 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 likegeteuid
orgetwd
orchdir
. Names likeReaddirnames
, 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 calledLikeThat
orLikethat
.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.
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments