50

Coming from a mainly c# background, I'm used to using the term "interface" for describing an object with no implementation that defines behaviour. In c#, the convention is to prepend interface names with "I", as in IEnumerable, etc.

Of course, the concept has different names in different languages. In Swift, the same concept is called a "protocol". When I'm developing protocols, I often have very similar names for the protocol and a class that implements it. So far, I've been appending the word "protocol" to these objects in the same way I'd use "I" in c#, as in EnumerableProtocol, etc.

Any thoughts on a naming convention for protocols in swift?

closed as primarily opinion-based by gnat, Dan Pichelman, GlenH7, Kilian Foth, user40980 Nov 26 '14 at 16:36

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
  • In general the terminology used in a protocol name should convey an ability. Equatable classes can be equated, NSCopying classes can by copied, etc. The only exception that comes to mind are delegates and data sources, which are SomethingDelegate or SomethingDataSource. I think the distinction is that the owning classes will have something like var dataSource: SomethingDataSource, but you won't see something like var foo: Equatable. – Ben Leggiero Jan 4 '17 at 13:36
78

Swift has matured significantly in the years since this answer was written. The design guidelines now state:

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

Thank you to David James for spotting this!

Original Answer

Using some form of Hungarian Notation can be a good idea – to represent important concepts that cannot be encoded inside the type system. However, the fact that some identifier refers to a protocol is part of the type system in Swift (and C#), and as such any prefix or suffix only adds noise. Clear prefixes or suffixes are a better idea for concepts such as exceptions or events.

In the absence of an official style guide for Swift, we have to come up with our own, or borrow from existing guides or code. For example, the Objective-C style guide for Cocoa contains this section:

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.

However, the advice of the second point is no longer applicable:

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

Here, the …Protocol suffix was used in order to disambiguate the protocol from the class.

The Swift Standard Library contains the protocols Equatable, Comparable, and Printable. These do not use the Cocoa “…ing” form, but rather the “…able” suffix to declare that any instance of this type must support a certain operation.


Conclusion

In a few cases where a protocol only has one relevant implementation, a “…Protocol” suffix can make sense so that the class and protocol can have the same name. However, this should be limited to such cases only.

Otherwise, the name should be some noun reflecting what operations this protocol contains. Using an “…ing” or “…able” form of a verb can be a good starting point, and such names are unlikely to conflict with class names.

The name EquatableProtocol is not recommendable. The name Equatable or Equating would be far better, and I do not expect any class to have the name Equatable. In this case, the Protocol suffix is noise.

  • 6
    FooDelegate is also common (at least for delegates, which are nearly always protocols...maybe actually always) – Stripes Mar 27 '15 at 16:34
  • 2
    Per Swift API design guidelines: swift.org/documentation/api-design-guidelines >> 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). – David James Jun 27 '17 at 13:24
  • 1
    @amon how should I name protocol for my class BluetoothService or UserDataManager? "...ing" or "...able" doesn't fit here and I would like to avoid "Protocol" suffix, any ideas? According to Api Design Guidelines, protocol should be in this case a noun like BluetoothService, but what name should have implementation then? BluetoothServiceImpl? Btw. after many examples I've seen, I think C# has the best convetion with "I" prefix like IAnything, IEquatable, ISmthAware :D – Wojciech Kulik Jul 20 '18 at 20:42
  • 1
    @WojciechKulik I'm not sure what good names might be in your case. A lot depends on how those protocols will be used. However, …Service and …Manager names can be a kind of code smell – the name is basically the same if you remove that suffix. Some names to consider: Bluetooth, BluetoothConnecting, BluetoothProtocol, UserData, UserDataRepository, UserDataWriting, UserDataProtocol. – amon Jul 21 '18 at 10:53
  • 1
    @DeclanMcKenna naming can get quite subjective, and which name to choose is not always obvious. But in many cases protocols should be used to express some tightly scoped capability (compare also the interface segregation principle). – amon May 24 at 12:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.