Swift è maturato significativamente negli anni da quando è stata scritta questa risposta. Le linee guida di progettazione ora indicano :

• 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).

Grazie a David James per aver individuato questo!

Risposta originale

Utilizzare una qualche forma di Notazione ungherese può essere una buona idea: rappresentare concetti importanti che non possono essere codificati all'interno del sistema dei tipi. Tuttavia, il fatto che qualche identificatore si riferisca ad un protocollo è parte del sistema di tipi in Swift (e C #), e come tale qualsiasi prefisso o suffisso aggiunge solo rumore. I prefissi oi suffissi chiari sono un'idea migliore per concetti come eccezioni o eventi.

In assenza di una guida di stile ufficiale per Swift, dobbiamo trovare il nostro o prendere in prestito da guide o codici esistenti. Ad esempio, la guida allo stile Objective-C per Cocoa contiene questa sezione:

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.

Tuttavia, il consiglio del secondo punto non è più applicabile:

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

Qui è stato usato il suffisso …Protocol per disambiguare il protocollo dalla classe.

Swift Standard Library contiene i protocolli Equatable , Comparable e Printable . Questi non usano il modulo "... ing" di Cocoa, ma piuttosto il suffisso "... able" per dichiarare che qualsiasi istanza di questo tipo deve supportare una determinata operazione.

Conclusione

In alcuni casi in cui un protocollo ha solo un'implementazione rilevante, un suffisso "... Protocol" può avere senso in modo che la classe e il protocollo possano avere lo stesso nome. Tuttavia, questo dovrebbe essere limitato solo a questi casi.

Altrimenti, il nome dovrebbe essere un nome che riflette le operazioni contenute in questo protocollo. Usare una forma "... ing" o "... abile" di un verbo può essere un buon punto di partenza, e tali nomi difficilmente possono entrare in conflitto con i nomi di classe.

Il nome EquatableProtocol è non raccomandabile . Il nome Equatable o Equating sarebbe molto meglio, e non mi aspetto che nessuna classe abbia il nome Equatable . In questo caso, il suffisso Protocol è rumore.