66

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?

Michael Daw
  • 763
  • 1
  • 5
  • 5
  • 1
    http://meta.programmers.stackexchange.com/questions/6582/on-the-troubles-of-naming-and-terminology – gnat Nov 22 '14 at 19:38
  • 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`. – Ky - Jan 04 '17 at 13:36

1 Answers1

103

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.

Community
  • 1
amon
  • 132,749
  • 27
  • 279
  • 375
  • Very well explained. Thank you. I'd up-vote, but don't have the rep. – Michael Daw Nov 22 '14 at 23:15
  • 6
    FooDelegate is also common (at least for delegates, which are nearly always protocols...maybe actually always) – Stripes Mar 27 '15 at 16:34
  • I want to summarize, please correct me if i'm wrong. In SWIFT: protocol names should be “…ing” or “…able”. If it is noun, append "..Protocol" to it. – Nike Kov Feb 02 '17 at 07:55
  • @NikKov Not quite – you should always prefer an “…ing” or “…able”. To find a name for your protocol, the sentence “MyClass is …” should make sense, where MyClass is some type implementing that protocol. E.g. “MyClass is XmlSerializable” reads better than “MyClass is XmlSerializerProtocol”. The “…Protocol” suffix should only be used when you are creating a protocol for a single class, and the class name and protocol name would otherwise be the same. The “ObjectProtocol” is a good example. – amon Feb 02 '17 at 14:35
  • With ing and able is clear, but when protocol describing the object type (no other name, but noun) - that's where the difficultness appear. – Nike Kov Feb 03 '17 at 08:27
  • 4
    Per Swift API design guidelines: https://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
  • @DavidJames Thank you very much for finding that! This answer has been terribly out of date after all those years. I've edited the question to include your quote. – amon Jun 27 '17 at 20:01
  • 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
  • How do we define whether something is a thing or a capability? – Declan McKenna May 23 '19 at 10:13
  • 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 '19 at 12:01
  • One more thing as written in the design guidelines: `Follow case conventions. Names of types and protocols are UpperCamelCase. Everything else is lowerCamelCase.` – CyberMew Mar 09 '20 at 07:23