go - 接口(interface)命名约定 Golang

Question

我将发布我的代码:

/*
*  Role will ALWAYS reserve the session key "role".
 */
package goserver

const (
    ROLE_KEY string = "role"
)

type Role string

//if index is higher or equal than role, will pass
type RolesHierarchy []Role

func (r Role) String() string {
    return string(r)
}

func NewRole(session ServerSession) Role {
    return session.GetValue(ROLE_KEY).(Role)
}

func (this Role) IsRole(role Role, hierarchy RolesHierarchy) bool {
    if role == this {
        return true
    }
    if len(hierarchy) == 0 {
        return false
    }
    var thisI int = 0
    var roleI int = 0
    //Duped roles in hierarchy are verified in verifyConfig during parse
    for i, r := range hierarchy {
        if this == r {
            thisI = i
        }
        if role == r {
            roleI = i
        }
    }
    //TODO I can probably condense what follows into one if
    if thisI == 0 && roleI == 0 {
        return false
    }
    return thisI >= roleI
}

func (this *Role) AssumeRole(session ServerSession, role Role) {
    session.SetValue(ROLE_KEY, role)
    *this = role
}

需要注意的是，ServerSession也是一个接口(interface)，调用“ServerSessioner”对我来说感觉很奇怪。

我正在玩弄用 IsRole() 和 AssumeRole() 创建接口(interface)的想法，但是“Roler”似乎很不稳定。我突然意识到，除了标准的“er”后缀之外，我真的不知道或曾经遇到过接口(interface)的命名约定。我似乎确实记得 VS C++ 的约定是在所有内容前面加上一个“I”。这是“惯用语”吗？

有什么建议吗？

Answer 1

在您的情况下，我将它们命名为 RoleChecker 和 RoleAssumer，即“合并”的一个 RoleCheckerAssumer。或者，如果您使用单个界面，则可能是 RoleHelper 或 RoleChecker。

ServerSession 也可以，甚至只是 Session (尤其是在没有“客户端” session 的情况下)。另一方面，ServerSessioner 不好，Session 不是动词，也不是接口(interface)的方法。

---

关于约定的帖子很多。

Effective Go: Interface names:

By convention, one-method interfaces are named by the method name plus an -er suffix or similar modification to construct an agent noun: Reader, Writer, Formatter, CloseNotifier etc.

There are a number of such names and it's productive to honor them and the function names they capture. Read, Write, Close, Flush, String and so on have canonical signatures and meanings. To avoid confusion, don't give your method one of those names unless it has the same signature and meaning. Conversely, if your type implements a method with the same meaning as a method on a well-known type, give it the same name and signature; call your string-converter method String not ToString.

Interface Types @ What's in a name? - Talks at golang.org

Interfaces that specify just one method are usually just that function name with 'er' appended to it.

type Reader interface {
    Read(p []byte) (n int, err error)
}

Sometimes the result isn't correct English, but we do it anyway:

type Execer interface {
    Exec(query string, args []Value) (Result, error)
}

Sometimes we use English to make it nicer:

type ByteReader interface {
    ReadByte() (c byte, err error)
}

When an interface includes multiple methods, choose a name that accurately describes its purpose (examples: net.Conn, http.ResponseWriter, io.ReadWriter).

对于接收者名称，请勿使用 this 或 self 或类似名称。而是:

Receivers @ What's in a name? - Talks at golang.org

Receivers are a special kind of argument.

By convention, they are one or two characters that reflect the receiver type, because they typically appear on almost every line:

func (b *Buffer) Read(p []byte) (n int, err error)

func (sh serverHandler) ServeHTTP(rw ResponseWriter, req *Request)

func (r Rectangle) Size() Point

Receiver names should be consistent across a type's methods. (Don't use r in one method and rdr in another.)

Go Code Review Comments: Receiver Names:

The name of a method's receiver should be a reflection of its identity; often a one or two letter abbreviation of its type suffices (such as "c" or "cl" for "Client"). Don't use generic names such as "me", "this" or "self", identifiers typical of object-oriented languages that place more emphasis on methods as opposed to functions. The name need not be as descriptive as that of a method argument, as its role is obvious and serves no documentary purpose. It can be very short as it will appear on almost every line of every method of the type; familiarity admits brevity. Be consistent, too: if you call the receiver "c" in one method, don't call it "cl" in another.