接口命名约定Golang

Dal*_*ale 15 naming interface naming-conventions go

我只是发布我的代码:

/*
*  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
}
Run Code Online (Sandbox Code Playgroud)

应该注意的是,ServerSession也是一个接口,调用"ServerSessioner"对我来说感觉很难受.

我正在尝试使用IsRole()和AssumeRole()创建一个接口,但"Roler"似乎非常不稳定.我突然意识到,除了标准的"呃"后缀之外,我真的不知道或者曾经遇到过接口的命名约定.我似乎记得VS C++的惯例就是在所有内容之前抛出一个"我".这是"惯用语"吗?

有什么建议?

icz*_*cza 29

在你的情况我也只是他们的名字RoleCheckerRoleAssumer中,"合并"一个RoleCheckerAssumer.或者,如果您使用单个界面,那可能是RoleHelperRoleChecker.

ServerSession也很好,甚至只是Session(特别是如果没有"客户"会话).ServerSessioner另一方面是坏的,Session不是动词而不是界面的方法.


关于这些公约的帖子很多.

有效Go:接口名称:

按照惯例,一个方法接口由该方法name加上后缀-er或类似的修改命名构建的试剂名:Reader,Writer,Formatter,CloseNotifier等.

有许多这样的名称,它们很有价值,以及它们捕获的功能名称.Read,Write,Close,Flush,String等有规范签名和意义.为避免混淆,请不要将您的方法作为其中一个名称,除非它具有相同的签名和含义.相反,如果您的类型实现的方法与众所周知类型的方法具有相同的含义,请为其指定相同的名称和签名; String不要调用你的字符串转换器方法ToString.

接口类型@名称中有什么? - 在golang.org上谈话

仅指定一个方法的接口通常只是附加了"er"的函数名称.

type Reader interface {
    Read(p []byte) (n int, err error)
}
Run Code Online (Sandbox Code Playgroud)

有时结果不是正确的英语,但我们仍然这样做:

type Execer interface {
    Exec(query string, args []Value) (Result, error)
}
Run Code Online (Sandbox Code Playgroud)

有时我们使用英语使其更好:

type ByteReader interface {
    ReadByte() (c byte, err error)
}
Run Code Online (Sandbox Code Playgroud)

当接口包含多个方法时,请选择准确描述其用途的名称(示例:net.Conn,http.ResponseWriter,io.ReadWriter).

对于接收器的名称,不使用thisself或类似的.代替:

接收器@名称中有什么? - 在golang.org上谈话

接收者是一种特殊的论点.

按照惯例,它们是反映接收器类型的一个或两个字符,因为它们通常出现在几乎每一行上:

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

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

func (r Rectangle) Size() Point
Run Code Online (Sandbox Code Playgroud)

接收者名称在类型的方法中应该是一致的.(不要在一种方法中使用r而在另一种方法中使用rdr.)

Go Code Review评论:接收者姓名:

方法接收者的名字应该反映其身份; 通常,其类型的一个或两个字母缩写就足够了(例如"客户"的"c"或"cl").不要使用通用名称,例如"me","this"或"self",这是面向对象语言的典型标识符,它们更强调方法而不是函数.名称不必像方法论证那样具有描述性,因为它的作用是显而易见的,不起任何文件目的.它可以很短,因为它几乎出现在每种类型的每个方法的每一行上; 熟悉承认简洁.也要保持一致:如果你用一种方法调用接收器"c",不要把它称为"cl".

  • @Dale你做任何你想做的事.没有人会强迫你做任何事情.只要你"独自"编码它就不会打扰别人.但是,如果您想与他人合作,或者其他人必须使用您的代码,您需要使用"通用"语言.关于`this`和`self`作为方法接收器:[在Go中命名接收器变量'self'误导或良好实践?](http://stackoverflow.com/questions/23482068/in-go-is-naming -the接收器,可变自我误导,或好的做法) (3认同)
  • 单一方法接口“更简单”。“Is<something>()”让我失望。我最终只使用了“checker()”。是的,抱歉,不会使用单个或两个字母标识符。我不在乎这里的惯用语是什么。我知道六种语言使用 this 或 self,为什么我会在这里打破约定,仅仅因为语言规范中的某些文档说我应该这样做?这个或自我正是我的意思和我想要的。归根结底,我需要阅读我的代码,如果我在意大利面条中翻找一些单字母标识符,那么有什么意义呢? (2认同)

Dal*_*ale 4

我明白了,事实证明我可以使用“呃”约定。

/*
*  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
}
Run Code Online (Sandbox Code Playgroud)

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