Swift-style-guide: 协议命名

我认为将 C# 名称样式转换为 Swift 会很困难。 接口的“I”在 .NET 中有效，因为命名空间不同。

至于动名词（“able”和“ing”），我相信它们的作用类似于英语：
“动名词是由动词加上“-ing”构成的名词。

例如：我需要散列（动词）这个类，它是可散列的（动名词）吗？ 我要比较（动词），这个类是否可比较（动名词）？

如果您查看 C#，它们也不会对所有接口使用动名词。 以 Point（类）和 IPoint（实现 X 和 Y 的接口）为例。 使一些有针对性的东西会有点误导。

UITableViewDelegate 和 UITableViewDataSource 等协议对我来说很好。 我个人对 ...Protocol 后缀没有任何问题，但我不希望将其作为一般规则。 有时 'able' 效果更好，有时其他后缀也有意义，例如 ...Delegate 或 ...DataSource。

我相信如果今天创建，它们将被称为 UITableViewDelegateType 和 UITableViewDataSourceType。 Greg Heo 称之为“是一个”： http :

我自己的许多协议只封装了一个函数或属性。 Swift 对协议的命名没有问题，我认为这是一种非常干净的方法。

protocol bool {
   var bool: Bool {get}
}

struct Struct: bool {
   let bool = true
}

我将在需要时使用普通的委托和数据源命名约定，但对于仅用于组合对象的协议，我只是将Protocol放在名称中。 不确定这是否是最佳实践，当我研究它时，我找不到任何信息。

protocol AlertModalProtocol {
func titleText() -> String
func messageText() -> String
}

struct NewUserAlertModal: AlertModalProtocol {

    func titleText() -> String {
        return "Welcome new user"
    }

    func messageText() -> String {
        return "Thanks for joining the app."
    }
}

“类型”后缀似乎正在走恐龙的道路，尽管我认为我看到一个提案飞过，像@mitchellporter那样使用“协议”。

来自Swift API 设计指南：

描述某物是什么的协议应该读作名词（例如集合）。 描述能力的协议应该使用后缀able、ible 或ing 命名（例如Equatable、ProgressReporting）。

那很有意思。 根据我的经验，当 Thing 传统上是一个非抽象类时，需要 ThingType。 （即 Thing 是实现 ThingType 的具体类型，其他更具体的类型也实现了 ThingType。） NSObjectProtocol 就是此类事物的一个示例。

我将按照 API 设计指南草案的内容添加一些文本。

迅速
在看别人的代码时，我遇到了一个问题，描述的协议是什么，当它们是名词时，悄悄地不方便，因为我经常将它与类方法混淆。 为了解决这个问题，我认为，使用下一条规则的更好方法是：

When the protocol name is a noun - write ..Protocol (yes, even in swift);
例如PhotoModuleProtocol
When the protocol is an adverb or an adjective - write ..able, ..ing and so on;
例如可测试

在我看来，与 Swift 时髦的东西相比，现在最好明确地倒计时识别某人的代码的时间。

我在 2015 年发布了我的最后一条评论......从那时起我主要使用@gregheo之前分享的内容：

描述某物是什么的协议应该读作名词（例如集合）。 描述能力的协议应该使用后缀able、ible 或ing 命名（例如Equatable、ProgressReporting）。

例如，通常有一个基本模型类型，如下所示：

protocol BaseType {
    var objectId: String { get set }
    var createdAt: NSDate? { get set }
    var updatedAt: NSDate? { get set }
    func toJSON() -> [String: AnyObject]
    static func from(json: [String: AnyObject]) -> AnyObject
}

由于整个应用程序中的所有模型都需要此功能，因此它们都将符合BaseType 。 我实际上一直在应用程序名称之后命名此基本类型，因此如果您的应用程序名称是Instagram它将是InstagramType 。 现在我正在考虑这个，在名称中包含Type似乎有点毫无意义......没有理由你不能将它命名为BaseModel 、 InstagramModel或甚至只是Model 。

至于描述功能的协议，我也一直在使用able、ible 和ing 类型的后缀。

我不再在我的名字中使用protocol这个词，因为它感觉多余，而且我还觉得我在使用它是为了让任何人都非常容易理解“嘿，这是一个协议，而不是一个类”，感觉错误，因为协议应该被视为等同于类，如果不是在类之上，则 swift 。

因此，我没有通过在名称中包含协议来将它们单独列出，而是将其排除在外。 这只是我觉得正确的事情，我并没有声称这一切是对还是错。 甚至几年后，我总是在 Swift 中发现新事物，而我已经放弃试图弄清楚所有事情。 真的只是想尝试一下，看看社区在这一点上提出了什么:)

尽管如此，通过名词命名协议会导致添加一些词（可以是“..Model”、“..Type”等）来确定它是一个协议而不是一个类。 只是在使用什么样的这个词时发生变化 =)