Venant d'un arrière-plan principalement c #, je suis habitué à utiliser le terme "interface" pour décrire un objet sans implémentation définissant le comportement. En c #, la convention est d’ajouter des noms d’interface avec "I", comme dans IEnumerable, etc.

Bien entendu, le concept a différents noms dans différentes langues. Dans Swift, le même concept s'appelle un "protocole". Lorsque je développe des protocoles, j'ai souvent des noms très similaires pour le protocole et une classe qui l'implémente. Jusqu'ici, j'ai ajouté le mot "protocole" à ces objets de la même manière que j'utiliserais "I" en c #, comme dans EnumerableProtocol, etc.

Avez-vous des idées sur une convention de nommage pour les protocoles dans swift?

Swift a considérablement mûri au cours des années qui ont suivi cette réponse. Les directives de conception indiquent désormais :

• Les protocoles décrivant ce que quelque chose est devrait se lire comme des noms (par exemple Collection).

• Les protocoles qui décrivent une capacité doivent être nommés en utilisant les suffixes able, ibleou ing(par exemple Equatable, ProgressReporting).

Merci à David James d' avoir remarqué cela!

Réponse originale

Utiliser une forme de notation hongroise peut être une bonne idée - représenter des concepts importants qui ne peuvent pas être encodés dans le système de types. Cependant, le fait que certains identificateurs fassent référence à un protocole fait partie du système de types de Swift (et C #) et, de ce fait, tout préfixe ou suffixe n’ajoute que du bruit. Les préfixes ou suffixes clairs sont une meilleure idée pour des concepts tels que les exceptions ou les événements.

En l'absence d'un guide de style officiel pour Swift, nous devons inventer le nôtre ou emprunter des guides ou du code existants. Par exemple, le guide de style Objective-C pour Cocoa contient cette section:

Noms de classe et de protocole

Les protocoles doivent être nommés en fonction de la manière dont ils regroupent les comportements:

• La plupart des protocoles regroupent des méthodes qui ne sont associées à aucune classe en particulier. Ce type de protocole doit être nommé afin que le protocole ne soit pas confondu avec une classe. Une convention courante consiste à utiliser une forme gerund (“... ing”):

  NSLocking- Bien.
  NSLock- Pauvre (semble être un nom pour une classe).

• Certains protocoles regroupent un certain nombre de méthodes non liées (plutôt que de créer plusieurs petits protocoles distincts). Ces protocoles ont tendance à être associés à une classe qui est l'expression principale du protocole. Dans ces cas, la convention est de donner au protocole le même nom que la classe.

  Un exemple de ce type de protocole est le NSObjectprotocole. Ce protocole regroupe les méthodes que vous pouvez utiliser pour interroger n'importe quel objet sur sa position dans la hiérarchie de classes, pour lui faire appeler des méthodes spécifiques et pour incrémenter ou décrémenter son décompte de références. Étant donné que la NSObjectclasse fournit l'expression principale de ces méthodes, le protocole porte le nom de la classe.

Toutefois, l'avis du deuxième point n'est plus applicable:

L'espace de noms des classes et des protocoles étant unifié dans Swift, le NSObjectprotocole dans Objective-C est remappé NSObjectProtocoldans Swift. ( source )

Ici, le …Protocolsuffixe a été utilisé afin de distinguer le protocole de la classe.

La bibliothèque standard Swift contient les protocoles Equatable, Comparableet Printable. Celles-ci n'utilisent pas la forme “… ing” de cacao, mais plutôt le suffixe “… capable” de déclarer que toute instance de ce type doit prendre en charge une certaine opération.

Conclusion

Dans quelques cas où un protocole n'a qu'une seule implémentation pertinente, un suffixe «… Protocole» peut avoir un sens, de sorte que la classe et le protocole puissent avoir le même nom. Toutefois, cela devrait être limité à de tels cas seulement.

Sinon, le nom devrait être un nom indiquant les opérations contenues dans ce protocole. L'utilisation d'un verbe «… ing» ou «… capable» peut constituer un bon point de départ et il est peu probable que ces noms entrent en conflit avec les noms de classe.

Le nom EquatableProtocoln'est pas recommandé . Le nom Equatableou Equatingserait beaucoup mieux, et je ne m'attends pas à ce qu'une classe ait le nom Equatable. Dans ce cas, le Protocolsuffixe est bruit.