接口命名约定 Golang

Question

我只是 post 我的代码：

/*
*  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也是一个接口，调用"ServerSessioner"对我来说感觉很不稳定。

我正在考虑使用 IsRole() 和 AssumeRole() 创建接口的想法，但是 "Roler" 看起来很不稳定。我突然意识到，除了标准的 "er" 后缀之外，我真的不知道或从未遇到过接口的命名约定。我似乎确实记得 VS C++ 惯例是在所有内容前面抛出一个 "I" 。这是"idiomatic"吗？

有什么建议吗？

Answer 1

在golang中，按照惯例，单方法接口名称是表示动作执行者的名词。例如，

the `Read` method implements the `Reader` interface, and
the `Generate` method implements the `Generator` interface.

最好将约定的细节说清楚，不管它们 are.This 在只有一个功能或接口需要一组非常具体的功能时表现如何

有一种做法是在函数的最小公分母前使用 I 前缀，在这种情况下，IRole 将是一个更好的接口名称，因为该接口定义了两个必须满足的函数通过代表 Role

的所有类型

Answer 2

我明白了，原来我可以使用 "er" 约定。

/*
*  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

type RoleChecker interface {
    IsRole(Role, RolesHierarchy) bool
}

type RoleAssumer interface {
    AssumeRole(ServerSession, Role)
}

type RoleCheckerAssumer interface {
    RoleChecker
    RoleAssumer
}

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
}

谢谢 Sarathsp 让我正确地思考这个问题。

Answer 3

在你的情况下，我将它们命名为 RoleChecker 和 RoleAssumer，"merged" 一个 RoleCheckerAssumer。或者，如果您使用单个界面，则可以是 RoleHelper 或 RoleChecker.

ServerSession 也可以，甚至只是 Session（尤其是在没有 "client" 会话的情况下）。另一方面，ServerSessioner 不好，Session 不是动词，也不是接口的方法。

关于约定的帖子很多。

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.

接口命名约定 Golang

Interface naming convention Golang

go

interface

naming-conventions

naming