Swift amadureceu significativamente nos anos desde que esta resposta foi escrita. As diretrizes de design agora são :

• Protocols that describe what something is should read as nouns (e.g. Collection).

• Protocols that describe a capability should be named using the suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).

Obrigado a David James por identificar isso!

Resposta original

Usar alguma forma de notação húngara pode ser uma boa ideia - representar conceitos importantes que não podem ser codificados dentro do sistema de tipos. No entanto, o fato de que algum identificador se refere a um protocolo é parte do sistema de tipos em Swift (e C #), e como tal, qualquer prefixo ou sufixo apenas adiciona ruído. Limpar prefixos ou sufixos são uma ideia melhor para conceitos como exceções ou eventos.

Na falta de um guia de estilo oficial para o Swift, temos que criar o nosso próprio, ou pedir emprestado de guias ou códigos existentes. Por exemplo, o guia de estilo Objective-C do Cocoa contém esta seção:

Class and Protocol Names

Protocols should be named according to how they group behaviors:

• Most protocols group related methods that aren’t associated with any class in particular. This type of protocol should be named so that the protocol won’t be confused with a class. A common convention is to use a gerund (“...ing”) form:

  NSLocking – Good.
  NSLock – Poor (seems like a name for a class).

• Some protocols group a number of unrelated methods (rather than create several separate small protocols). These protocols tend to be associated with a class that is the principal expression of the protocol. In these cases, the convention is to give the protocol the same name as the class.

  An example of this sort of protocol is the NSObject protocol. This protocol groups methods that you can use to query any object about its position in the class hierarchy, to make it invoke specific methods, and to increment or decrement its reference count. Because the NSObject class provides the primary expression of these methods, the protocol is named after the class.

No entanto, o conselho do segundo ponto não é mais aplicável:

Because the namespace of classes and protocols is unified in Swift, the NSObject protocol in Objective-C is remapped to NSObjectProtocol in Swift. (source)

Aqui, o sufixo …Protocol foi usado para desambiguar o protocolo da classe.

A Biblioteca padrão Swift contém os protocolos Equatable , Comparable e Printable . Eles não usam o formulário “… ing” do Cocoa, mas sim o sufixo “… able” para declarar que qualquer instância desse tipo deve suportar uma determinada operação.

Conclusão

Em alguns casos em que um protocolo tem apenas uma implementação relevante, um sufixo “… Protocolo” pode fazer sentido para que a classe e o protocolo possam ter o mesmo nome. No entanto, isso deve ser limitado apenas a esses casos.

Caso contrário, o nome deve ser algum substantivo que reflita quais operações este protocolo contém. Usar uma forma “… ing” ou “… able” de um verbo pode ser um bom ponto de partida, e é improvável que esses nomes entrem em conflito com nomes de classes.

O nome EquatableProtocol é não recomendável . O nome Equatable ou Equating seria muito melhor, e não espero que nenhuma classe tenha o nome Equatable . Nesse caso, o sufixo Protocol é ruído.