Swift ha madurado significativamente en los años transcurridos desde que se escribió esta respuesta. Las pautas de diseño ahora establecen : / p>

  

• Los protocolos que describen qué es algo deben leerse como nombres (por ejemplo, Collection ).

  

• Los protocolos que describen una capacidad de deben nombrarse con los sufijos able , ible o ing (por ejemplo, Equatable , ProgressReporting ).

  

Gracias a David James por detectar esto.

Respuesta original

Utilizar algún tipo de notación húngara puede ser una buena idea: representar conceptos importantes que no se pueden codificar dentro del sistema de tipos. Sin embargo, el hecho de que algún identificador se refiera a un protocolo es parte del sistema de tipos en Swift (y C #), y como tal, cualquier prefijo o sufijo solo agrega ruido. Los prefijos o sufijos claros son una mejor idea para conceptos como excepciones o eventos.

En ausencia de una guía de estilo oficial para Swift, tenemos que crear la nuestra o pedir prestado de las guías o códigos existentes. Por ejemplo, la guía de estilo de Objective-C para Cocoa contiene esta sección:

  

Nombres de clase y protocolo

     

Los protocolos deben nombrarse de acuerdo con la forma en que agrupan los comportamientos:

     

• La mayoría de los protocolos agrupa métodos relacionados que no están asociados con ninguna clase en particular. Este tipo de protocolo se debe nombrar para que el protocolo no se confunda con una clase. Una convención común es utilizar un formulario de gerundio ("... ing"):

       

  NSLocking - Bien.
  NSLock - Pobre (parece un nombre para una clase).

  

• Algunos protocolos agrupan varios métodos no relacionados (en lugar de crear varios protocolos pequeños separados). Estos protocolos tienden a estar asociados con una clase que es la expresión principal del protocolo. En estos casos, la convención es dar al protocolo el mismo nombre que la clase.

       

  Un ejemplo de este tipo de protocolo es el protocolo NSObject . Este protocolo agrupa los métodos que puede usar para consultar cualquier objeto sobre su posición en la jerarquía de clases, para hacer que invoque métodos específicos y para aumentar o disminuir su recuento de referencias. Debido a que la clase NSObject proporciona la expresión principal de estos métodos, el protocolo recibe el nombre de la clase.

  

Sin embargo, el consejo del segundo punto ya no es aplicable:

  

Debido a que el espacio de nombres de las clases y los protocolos se unifica en Swift, el protocolo NSObject en Objective-C se vuelve a correlacionar con NSObjectProtocol en Swift. ( fuente )

Aquí, el sufijo …Protocol se usó para desambiguar el protocolo de la clase.

El Swift Standard Library contiene los protocolos Equatable , Comparable y Printable . Estos no utilizan el formulario "... ing" de Cocoa, sino el sufijo "... able" para declarar que cualquier instancia de este tipo debe admitir una determinada operación.

Conclusión

En algunos casos en los que un protocolo solo tiene una implementación relevante, un sufijo "... Protocol" puede tener sentido para que la clase y el protocolo puedan tener el mismo nombre. Sin embargo, esto debería limitarse únicamente a tales casos.

De lo contrario, el nombre debe ser un nombre que refleje las operaciones que contiene este protocolo. El uso de la forma “... ing” o “... capaz” de un verbo puede ser un buen punto de partida, y es poco probable que dichos nombres entren en conflicto con los nombres de clase.

El nombre EquatableProtocol es no recomendable . El nombre Equatable o Equating sería mucho mejor, y no espero que ninguna clase tenga el nombre Equatable . En este caso, el sufijo Protocol es ruido.