Swift Protocol Naming Conventions [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

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?

Answer 1

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.