Protocol Naming

[minmadic]

Is there a preferred way to name protocols? Like using the suffix "able" or "ing". I did come across this StackExchange Question with a pretty good answer.

Should this be added to the style guide?

[RobertGummesson]

I think it would be difficult to translate the C# name styling into Swift. The ‘I’ for interface works in .NET because the namespace differences.

As for gerunds ("able" and "ing"), I believe they work similar as in the English language:
“A gerund is a noun made from a verb by adding "-ing."

For example: I need to hash (verb) this class, is it hashable (gerund)? I want to compare (verb), is this class comparable (gerund)?

If you look at C#, they don't use gerunds for all interfaces either. Take the Point (class) and IPoint (interface which implements X and Y). Making something pointable would be a bit misleading.

Protocols such as UITableViewDelegate and UITableViewDataSource are fine to me. I personally don't have any issues with the ...Protocol suffix but I wouldn't want it as a general rule. Sometimes 'able' works better, sometimes other suffixes makes sense such as ...Delegate or ...DataSource.

[JessyCatterwaul]

I believe that if created today, they would be called UITableViewDelegateType and UITableViewDataSourceType. Greg Heo calls this "is a": http://www.skilled.io/gregheo/what-the-55-swift-standard-library-protocols-taught-me

Many of my own protocols encapsulate only one function or property. Swift has no problem with naming the protocol the same as that, and I think that's a very clean approach.

protocol bool {
   var bool: Bool {get}
}

struct Struct: bool {
   let bool = true
}

[mitchellporter]

I'll use the normal delegate and datasource naming convention when needed, but for protocols that are simply used to compose objects I've just been putting Protocol in the name. Not sure if this is a best practice or not, when I researched it I couldn't find any info.

protocol AlertModalProtocol {
func titleText() -> String
func messageText() -> String
}

struct NewUserAlertModal: AlertModalProtocol {

    func titleText() -> String {
        return "Welcome new user"
    }

    func messageText() -> String {
        return "Thanks for joining the app."
    }
}

[gregheo]

The "Type" suffix seems to be going the way of the dinosaur although I thought I saw a proposal fly by to use "Protocol" as @mitchellporter does.

From the Swift 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).

[JessyCatterwaul]

That's interesting. In my experience, ThingType has been needed when Thing would traditionally have been a non-abstract class. (i.e. Thing is a concrete type that implements ThingType, and other types that are more specific also implement ThingType.) NSObjectProtocol is an example of this kind of thing.

[rayfix]

I will add some text along the lines of the API Design Guidelines draft.

[NikKovIos]

SWIFT
While watching someone else's code, i've faced a problem, that protocols which are describing, what is it, when they are nouns, are quietly inconvenient, because i often confuse it with class methods. To solve this problem, i think, the better way to use next rule:

When the protocol name is a noun - write ..Protocol (yes, even in swift);
e.g. PhotoModuleProtocol
When the protocol is an adverb or an adjective - write ..able, ..ing and so on;
e.g. Testable

In my opinion it is better to explicitly now what is it to count down the time for recognizing someone's code, than Swift hipster's stuff.

[mitchellporter]

I posted my last comment back in 2015... since then I've migrated to mostly using what @gregheo shared earlier:

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

So for example there's normally a base model type that will look like this:

protocol BaseType {
    var objectId: String { get set }
    var createdAt: NSDate? { get set }
    var updatedAt: NSDate? { get set }
    func toJSON() -> [String: AnyObject]
    static func from(json: [String: AnyObject]) -> AnyObject
}

Since all models throughout the app will need this functionality, they will all conform to BaseType. I've actually been naming this base type after the name of the app, so if your app's name was Instagram it would be InstagramType. Now that I'm thinking about this, including Type in the name seems kind of pointless... there's no reason why you couldn't name it BaseModel, InstagramModel or even just Model.

As for protocols that describe capabilities I've been using the able, ible, and ing type suffixes too.

I stopped using the word protocol in my names because it felt redundant and I also felt like I was using it to make it super easy for anyone to understand "Hey, this is a protocol, not a class" which felt wrong since protocols are supposed to be looked at as equals to classes, if not above them, in swift.

So rather than single them out by including protocol in the name, I just leave it out. This is just what feels right to me, I'm not claiming any of this is right or wrong. Even years later I'm always discovering new things in Swift and I've given up on trying to figure everything out. Really just trying to experiment and see what the community comes up with at this point :)

[NikKovIos]

Still, naming protocols by noun result to add some word (it can be "..Model", "..Type" and so on) to determine, that it is a protocol and not a class. Changes just in what kind of this word to use =)