Исходя из в основном фона c #, я привык использовать термин «интерфейс» для описания объекта без реализации, определяющей поведение. В c # соглашение заключается в добавлении имен интерфейсов с помощью «I», например IEnumerable, и т. Д.

Конечно, у концепции разные названия на разных языках. В Swift та же концепция называется «протокол». Когда я разрабатываю протоколы, у меня часто бывают очень похожие имена для протокола и класса, который его реализует. До сих пор я добавлял слово «протокол» к этим объектам так же, как я использовал «Я» в c #, как EnumerableProtocolи т. Д.

Любые мысли о соглашении об именовании для протоколов в Swift?

Свифт значительно повзрослел за годы, прошедшие с момента написания этого ответа. Руководство по проектированию теперь заявляет :

• Протоколы, описывающие что-то , должны читаться как существительные (например Collection).

• Протоколы , которые описывают возможности должны быть названы с помощью суффиксов able, ibleили ing(например Equatable, ProgressReporting).

Спасибо Дэвиду Джеймсу за то, что он это заметил!

Оригинальный ответ

Хорошей идеей может быть использование некоторой формы венгерской нотации - для представления важных понятий, которые не могут быть закодированы внутри системы типов. Однако тот факт, что некоторый идентификатор ссылается на протокол, является частью системы типов в Swift (и C #), и поэтому любой префикс или суффикс только добавляет шум. Четкие префиксы или суффиксы - лучшая идея для таких понятий, как исключения или события.

В отсутствие официального руководства по стилю для Swift, нам приходится придумывать свои собственные или заимствовать из существующих руководств или кода. Например, руководство по стилю Objective C для Какао содержит этот раздел:

Имена классов и протоколов

Протоколы должны быть названы в соответствии с тем, как они группируют поведение:

• Большинство протоколов группируют связанные методы, которые не связаны ни с каким конкретным классом. Этот тип протокола должен быть назван так, чтобы протокол не был перепутан с классом. Общепринятым условием является использование формы gerund («... ing»):

  NSLocking- Хороший.
  NSLock- Плохо (кажется, имя для класса).

• Некоторые протоколы группируют несколько несвязанных методов (вместо того, чтобы создавать несколько отдельных небольших протоколов). Эти протоколы, как правило, связаны с классом, который является основным выражением протокола. В этих случаях соглашение должно давать протоколу то же имя, что и класс.

  Примером такого рода протокола является NSObjectпротокол. Этот протокол группирует методы, которые можно использовать для запроса любого объекта о его положении в иерархии классов, чтобы он вызывал определенные методы, а также для увеличения или уменьшения его счетчика ссылок. Поскольку NSObjectкласс предоставляет основное выражение этих методов, протокол назван в честь класса.

Однако рекомендация по второму пункту больше не применима:

Поскольку пространство имен классов и протоколов унифицировано в Swift, NSObjectпротокол в Objective-C переназначается NSObjectProtocolв Swift. ( источник )

Здесь …Protocolсуффикс использовался для устранения неоднозначности протокола от класса.

Стандартная библиотека Swift содержит протоколы Equatable, Comparableи Printable. Они не используют форму «… ing» Какао, а скорее суффикс «... способный», чтобы объявить, что любой экземпляр этого типа должен поддерживать определенную операцию.

Заключение

В некоторых случаях, когда протокол имеет только одну соответствующую реализацию, может иметь смысл суффикс «… Protocol», чтобы класс и протокол могли иметь одно и то же имя. Однако это должно быть ограничено только такими случаями.

В противном случае имя должно быть каким-то существительным, отражающим, какие операции содержит этот протокол. Хорошей отправной точкой может быть использование формы глагола «… ing» или «способный», и такие имена вряд ли будут конфликтовать с именами классов.

Название EquatableProtocolэто не рекомендуется . Имя Equatableили Equatingбыло бы намного лучше, и я не ожидаю, что у какого-либо класса будет имя Equatable. В этом случае Protocolсуффиксом является шум.