Apple Swift API Design Guideline

122
Swift API Design Guidelines by Apple Inc. Sai Li @ Yowoo Tech. 2016 / 11 / 11

Transcript of Apple Swift API Design Guideline

Page 1: Apple Swift API Design Guideline

Swift API Design Guidelinesby Apple Inc.

Sai Li @ Yowoo Tech. 2016 / 11 / 11

Page 2: Apple Swift API Design Guideline

Reference

• Apple Swift API Design Guidelines

• Function Naming In Swift 3

Page 3: Apple Swift API Design Guideline

Fundamentals

• Clarity at the point of use

• Clarity is more important than brevity

• Write a documentation comment

Page 4: Apple Swift API Design Guideline

Clarity at the point of use

Page 5: Apple Swift API Design Guideline

Clarity at the point of use

• Declared once but used repeatedly

Page 6: Apple Swift API Design Guideline

Clarity at the point of use

• Declared once but used repeatedly

• Clear and Concise

Page 7: Apple Swift API Design Guideline

Clarity at the point of use

• Declared once but used repeatedly

• Clear and Concise

• When evaluating a design, reading a declaration is seldom sufficient; always examine a use case to make sure it looks clear in context.

Page 8: Apple Swift API Design Guideline

Clarity is more important than brevity

Page 9: Apple Swift API Design Guideline

Clarity is more important than brevity

• non-goal to enable the smallest possible code fewest characters

Page 10: Apple Swift API Design Guideline

Clarity is more important than brevity

• non-goal to enable the smallest possible code fewest characters

• Brevity: a side-effect of the strong type system and features

Page 11: Apple Swift API Design Guideline

Write a documentation comment

Page 12: Apple Swift API Design Guideline

Write a documentation comment

• Every declaration

Page 13: Apple Swift API Design Guideline

Write a documentation comment

• Every declaration

• Don’t put it off

Page 14: Apple Swift API Design Guideline

Naming

Page 15: Apple Swift API Design Guideline

Promote Clear Usage• Include all the words needed to avoid ambiguity

Page 16: Apple Swift API Design Guideline

Promote Clear Usage• Include all the words needed to avoid ambiguity

Page 17: Apple Swift API Design Guideline

Promote Clear Usage• Include all the words needed to avoid ambiguity

Page 18: Apple Swift API Design Guideline

Omit needless words• Every word in a name should convey salient

information at the use site

Page 19: Apple Swift API Design Guideline

Omit needless words• Every word in a name should convey salient

information at the use site

redundant

Page 20: Apple Swift API Design Guideline

Name variables, parameters, and associated types according to their Roles• rather than their type

Page 21: Apple Swift API Design Guideline

Name variables, parameters, and associated types according to their Roles• rather than their type

Page 22: Apple Swift API Design Guideline

Name variables, parameters, and associated types according to their Roles• rather than their type

Page 23: Apple Swift API Design Guideline

Name variables, parameters, and associated types according to their Roles• rather than their type

Page 24: Apple Swift API Design Guideline

Name variables, parameters, and associated types according to their Roles• rather than their type

Page 25: Apple Swift API Design Guideline

Sometimes….

Page 26: Apple Swift API Design Guideline

Compensate for weak type information

Page 27: Apple Swift API Design Guideline

Compensate for weak type information• NSObject, Any, AnyObject, Int or String…

Page 28: Apple Swift API Design Guideline

Compensate for weak type information• NSObject, Any, AnyObject, Int or String…

• precede each weakly typed parameter with a noun describing its role

Page 29: Apple Swift API Design Guideline

Compensate for weak type information• NSObject, Any, AnyObject, Int or String…

• precede each weakly typed parameter with a noun describing its role

Page 30: Apple Swift API Design Guideline

Compensate for weak type information• NSObject, Any, AnyObject, Int or String…

• precede each weakly typed parameter with a noun describing its role

Page 31: Apple Swift API Design Guideline

Compensate for weak type information• NSObject, Any, AnyObject, Int or String…

• precede each weakly typed parameter with a noun describing its role

Page 32: Apple Swift API Design Guideline

Grammatical English Phrases

Page 33: Apple Swift API Design Guideline

Sometimes…

Page 34: Apple Swift API Design Guideline

Factory method & init()

Page 35: Apple Swift API Design Guideline

Factory method & init()• “make”:

Page 36: Apple Swift API Design Guideline

Factory method & init()• “make”:

• x.makeIterator()

Page 37: Apple Swift API Design Guideline

Factory method & init()• “make”:

• x.makeIterator()

• x.makeWidget(cogCount: 47)

Page 38: Apple Swift API Design Guideline

Factory method & init()• “make”:

• x.makeIterator()

• x.makeWidget(cogCount: 47)

Page 39: Apple Swift API Design Guideline

Factory method & init()• “make”:

• x.makeIterator()

• x.makeWidget(cogCount: 47)

Page 40: Apple Swift API Design Guideline

Factory method & init()• “make”:

• x.makeIterator()

• x.makeWidget(cogCount: 47)

Page 41: Apple Swift API Design Guideline

Factory method & init()• “make”:

• x.makeIterator()

• x.makeWidget(cogCount: 47)

Page 42: Apple Swift API Design Guideline

Factory method & init()• “make”:

• x.makeIterator()

• x.makeWidget(cogCount: 47)

Page 43: Apple Swift API Design Guideline

Side-effects

Page 44: Apple Swift API Design Guideline

Side-effects• Without: Noun

• x.distance(to: y) i.successor()

Page 45: Apple Swift API Design Guideline

Side-effects• Without: Noun

• x.distance(to: y) i.successor()

• With: Verb

• x.sort()x.append(y)

Page 46: Apple Swift API Design Guideline

Verb: Mutating / Nonmutating• “ed” or “ing”

Page 47: Apple Swift API Design Guideline

“ed”

Page 48: Apple Swift API Design Guideline

“ing”

Page 49: Apple Swift API Design Guideline

Noun: mutating/ nonmutating• “form”

Page 50: Apple Swift API Design Guideline
Page 51: Apple Swift API Design Guideline

• Booleaneg: x.isEmpty, line1.intersects(line2)

Page 52: Apple Swift API Design Guideline

• Booleaneg: x.isEmpty, line1.intersects(line2)

• Protocols what something is -> Noun eg: Collection

Page 53: Apple Swift API Design Guideline

• Booleaneg: x.isEmpty, line1.intersects(line2)

• Protocols what something is -> Noun eg: Collection

• Protocols: capability -> -able, -ible, -ingeg: Equatable, ProgressReporting

Page 54: Apple Swift API Design Guideline

• Booleaneg: x.isEmpty, line1.intersects(line2)

• Protocols what something is -> Noun eg: Collection

• Protocols: capability -> -able, -ible, -ingeg: Equatable, ProgressReporting

• types, properties, variables, and constants -> nouns.

Page 55: Apple Swift API Design Guideline

Term of Art

Page 56: Apple Swift API Design Guideline

Use Terminology Well

Page 57: Apple Swift API Design Guideline

Use Terminology Well• Avoid obscure terms

Don’t say “epidermis” if “skin” will serve your purpose

Page 58: Apple Swift API Design Guideline

Use Terminology Well• Avoid obscure terms

Don’t say “epidermis” if “skin” will serve your purpose

• Stick to the established meaning

Don’t surprise an expert

Don’t confuse a beginner

Page 59: Apple Swift API Design Guideline

Use Terminology Well• Avoid obscure terms

Don’t say “epidermis” if “skin” will serve your purpose

• Stick to the established meaning

Don’t surprise an expert

Don’t confuse a beginner

• Avoid “non-standard” abbreviations

easily found by a web search.

Page 60: Apple Swift API Design Guideline

Embrace precedent

• Array > List

• sin(x) > verticalPositionOnUnitCircleAtOriginOfEndOfRadiusWithAngle(x), sine(x)

• Precedent > Avoid abbreviation

Page 61: Apple Swift API Design Guideline

Conventions• Document the complexity of computed property > O(1)

Page 62: Apple Swift API Design Guideline

Conventions

Page 63: Apple Swift API Design Guideline

Conventionsmethods and properties > free functions

Page 64: Apple Swift API Design Guideline

Conventionsmethods and properties > free functions

1. No obvious self min(x, y, z)

Page 65: Apple Swift API Design Guideline

Conventionsmethods and properties > free functions

1. No obvious self min(x, y, z)

2. function is unconstrained generic print(x)

Page 66: Apple Swift API Design Guideline

Conventionsmethods and properties > free functions

1. No obvious self min(x, y, z)

2. function is unconstrained generic print(x)

3. function syntax is part of the domain notation sin(x)

Page 67: Apple Swift API Design Guideline

Follow case conventions

Page 68: Apple Swift API Design Guideline

Follow case conventions• Types and Protocols: UpperCamelCase

else: lowerCamelCase

Page 69: Apple Swift API Design Guideline

Follow case conventions• Types and Protocols: UpperCamelCase

else: lowerCamelCase

• var utf8Bytes: [UTF8.CodeUnit] var isRepresentableAsASCII = truevar userSMTPServer: SecureSMTPServer

Page 70: Apple Swift API Design Guideline

Follow case conventions• Types and Protocols: UpperCamelCase

else: lowerCamelCase

• var utf8Bytes: [UTF8.CodeUnit] var isRepresentableAsASCII = truevar userSMTPServer: SecureSMTPServer

• var radarDetector: RadarScanner var enjoysScubaDiving = true

Page 71: Apple Swift API Design Guideline

Methods can share a base name• Methods can share a base name

Page 72: Apple Swift API Design Guideline

Methods can share a base name• Methods can share a base name

Page 73: Apple Swift API Design Guideline
Page 74: Apple Swift API Design Guideline
Page 75: Apple Swift API Design Guideline
Page 76: Apple Swift API Design Guideline
Page 77: Apple Swift API Design Guideline
Page 78: Apple Swift API Design Guideline

Parameters

Page 79: Apple Swift API Design Guideline
Page 80: Apple Swift API Design Guideline
Page 81: Apple Swift API Design Guideline
Page 82: Apple Swift API Design Guideline
Page 83: Apple Swift API Design Guideline
Page 84: Apple Swift API Design Guideline
Page 85: Apple Swift API Design Guideline
Page 86: Apple Swift API Design Guideline
Page 87: Apple Swift API Design Guideline

Defaulted Parameters

Page 88: Apple Swift API Design Guideline

Defaulted Parameters

Page 89: Apple Swift API Design Guideline

Defaulted Parameters

Page 90: Apple Swift API Design Guideline

Defaulted Parameters

Page 91: Apple Swift API Design Guideline

Defaulted Parameters

Page 92: Apple Swift API Design Guideline

Defaulted Parameters

the end of the parameter list

Page 93: Apple Swift API Design Guideline

Argument Labels

• Omit all labels when arguments can’t be usefully distinguished

• Value preserving type conversions

Page 94: Apple Swift API Design Guideline

Argument Labels

• Omit all labels when arguments can’t be usefully distinguished

• Value preserving type conversions

Page 95: Apple Swift API Design Guideline

Argument Labels

Page 96: Apple Swift API Design Guideline

Argument Labels

Page 97: Apple Swift API Design Guideline

Argument Labels(narrowing)

Page 98: Apple Swift API Design Guideline

Argument Labels(narrowing)

Page 99: Apple Swift API Design Guideline

Monomorphism• value preserving type conversion

Page 100: Apple Swift API Design Guideline

Monomorphism

Int8 Int64

• value preserving type conversion

Page 101: Apple Swift API Design Guideline

Monomorphism

Int8 Int64

• value preserving type conversion

Page 102: Apple Swift API Design Guideline

Monomorphism

Int8 Int64

• value preserving type conversion

Page 103: Apple Swift API Design Guideline

Monomorphism

Int8 Int64

• value preserving type conversion

Page 104: Apple Swift API Design Guideline

Arguments Labels(prepositional phrase)

• eg: x.removeBoxes(havingLength: 12)

Page 105: Apple Swift API Design Guideline

Arguments Labels(prepositional phrase)

• eg: x.removeBoxes(havingLength: 12)

Page 106: Apple Swift API Design Guideline

Arguments Labels(prepositional phrase)

• eg: x.removeBoxes(havingLength: 12)

Page 107: Apple Swift API Design Guideline

Arguments Labels(prepositional phrase)

• eg: x.removeBoxes(havingLength: 12)

Page 108: Apple Swift API Design Guideline

• If the first argument forms part of a grammatical phrase, omit its label

Page 109: Apple Swift API Design Guideline

• If the first argument forms part of a grammatical phrase, omit its label

Page 110: Apple Swift API Design Guideline

• If the first argument forms part of a grammatical phrase, omit its label

Page 111: Apple Swift API Design Guideline

• If the first argument forms part of a grammatical phrase, omit its label

Page 112: Apple Swift API Design Guideline

• If the first argument forms part of a grammatical phrase, omit its label

Page 113: Apple Swift API Design Guideline

• If the first argument forms part of a grammatical phrase, omit its label

Page 114: Apple Swift API Design Guideline

• Label closure parameters and tuple members in your API.

Page 115: Apple Swift API Design Guideline

• Label closure parameters and tuple members in your API.

Page 116: Apple Swift API Design Guideline

• Label closure parameters and tuple members in your API.

Page 117: Apple Swift API Design Guideline

• Label closure parameters and tuple members in your API.

Page 118: Apple Swift API Design Guideline

Take extra care with unconstrained polymorphism

• eg: Any, AnyObject, unconstrained polymorphism

Page 119: Apple Swift API Design Guideline

Take extra care with unconstrained polymorphism

• eg: Any, AnyObject, unconstrained polymorphism

Page 120: Apple Swift API Design Guideline

Take extra care with unconstrained polymorphism

• eg: Any, AnyObject, unconstrained polymorphism

Page 121: Apple Swift API Design Guideline

Take extra care with unconstrained polymorphism

• eg: Any, AnyObject, unconstrained polymorphism

Page 122: Apple Swift API Design Guideline

To be continued… Function Naming In Swift 3