来自主要是C＃的背景，我习惯于使用术语“接口”来描述对象，而该对象没有定义行为的实现。在c＃中，惯例是在接口名称前加上“ I”，如IEnumerable等等。

当然，该概念在不同的语言中具有不同的名称。在Swift中，相同的概念称为“协议”。在开发协议时，我经常为协议和实现它的类有非常相似的名称。到目前为止，我一直在将“ protocol”一词附加到这些对象上，就像在c＃中使用“ I”一样，在EnumerableProtocol等等中。

对快速命名协议的约定有何想法？

自从编写此答案以来，Swift已大大成熟。现在，设计准则指出：

• 描述某些事物的协议应读作名词（例如Collection）。

• 描述一个协议能力应该使用后缀命名able，ible或ing（例如Equatable，ProgressReporting）。

感谢大卫·詹姆斯（David James）发现这一点！

原始答案

使用某种形式的匈牙利表示法可能是一个好主意-表示无法在类型系统内编码的重要概念。但是，某些标识符引用协议这一事实是 Swift（和C＃）类型系统的一部分，因此任何前缀或后缀只会增加噪音。对于诸如异常或事件之类的概念，明确的前缀或后缀是一个更好的主意。

在没有Swift的正式样式指南的情况下，我们必须提出自己的指南，或者借鉴现有的指南或代码。例如，可可的Objective-C样式指南包含以下部分：

类和协议名称

协议应根据它们对行为的分组方式来命名：

• 大多数协议将与方法相关的方法归为一组，这些方法与特定的类无关。应当对这种类型的协议进行命名，以使该协议不会与类混淆。常见的约定是使用gerund（“ ... ing”）形式：

  NSLocking–好。
  NSLock–较差（好像是班级的名称）。

• 一些协议将许多不相关的方法组合在一起（而不是创建几个单独的小型协议）。这些协议倾向于与作为该协议主要表达的类相关联。在这些情况下，约定是为协议赋予与类相同的名称。

  这种协议的一个示例是NSObject协议。该协议对方法进行了分组，您可以使用这些方法来查询任何对象在类层次结构中的位置，使其调用特定的方法，以及增加或减少其引用计数。因为NSObject该类提供了这些方法的主要表达，所以协议以该类命名。

但是，第二点的建议不再适用：

由于类和协议的名称空间在Swift中是统一的，因此NSObjectObjective-C中的协议NSObjectProtocol在Swift中被重新映射。（来源）

在这里，使用…Protocol后缀是为了从类中消除协议的歧义。

在雨燕标准库包含了协议Equatable，Comparable和Printable。它们不使用可可“……”形式，而是使用“……”后缀来声明该类型的任何实例都必须支持某种操作。

结论

在某些协议仅具有一个相关实现的情况下，可以使用“…Protocol”后缀，以便类和协议可以具有相同的名称。但是，这仅应限于此类情况。

否则，名称应为一些名词，以反映此协议包含的操作。使用动词的“…ing”或“…able”形式可能是一个很好的起点，并且此类名称不太可能与类名称冲突。

这个名字EquatableProtocol是不值得推荐。名称Equatable或Equating会更好，而且我不希望任何班级都使用名称Equatable。在这种情况下，Protocol后缀是噪声。