8000 Merge branch 'master' into jspahrsummers-patch-2 · smashcoding/swift-style-guide@fe8c73e · GitHub
[go: up one dir, main page]

Skip to content

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Commit fe8c73e

Browse files
committed
Merge branch 'master' into jspahrsummers-patch-2
Conflicts: README.md
2 parents cf22f6b + bcb7586 commit fe8c73e

File tree

1 file changed

+58
-2
lines changed

1 file changed

+58
-2
lines changed

README.md

Lines changed: 58 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -79,7 +79,7 @@ _Rationale:_ It's rarely appropriate for top-level definitions to be specificall
7979

8080
#### When specifying a type, always associate the colon with the identifier
8181

82-
When specifying the type of an identifier, always put the colon immediately
82+
When specifying the type of an identifier, always put the colon immediately
8383
after the identifier, followed by a space and then the type name.
8484

8585
```swift
@@ -90,7 +90,7 @@ let timeToCoffee: NSTimeInterval = 2
9090
func makeCoffee(type: CoffeeType) -> Coffee { ... }
9191
```
9292

93-
_Rationale:_ The type specifier is saying something about the _identifier_ so
93+
_Rationale:_ The type specifier is saying something about the _identifier_ so
9494
it should be positioned with it.
9595

9696
#### Only explicitly refer to `self` when required
@@ -125,4 +125,60 @@ extension History {
125125

126126
_Rationale:_ This makes the capturing semantics of `self` stand out more in closures, and avoids verbosity elsewhere.
127127

128+
#### Prefer structs over classes
129+
130+
Unless you require functionality that can only be provided by a class (like identity or deinitializers), implement a struct instead.
131+
132+
Note that inheritance is (by itself) usually _not_ a good reason to use classes, because polymorphism can be provided by protocols, and implementation reuse can be provided through composition.
133+
134+
For example, this class hierarchy:
135+
136+
```swift
137+
class Vehicle {
138+
let numberOfWheels: Int
139+
140+
init(numberOfWheels: Int) {
141+
self.numberOfWheels = numberOfWheels;
142+
}
143+
144+
func maximumTotalTirePressure(pressurePerWheel: Float) -> Float {
145+
return pressurePerWheel * numberOfWheels
146+
}
147+
}
148+
149+
class Bicycle: Vehicle {
150+
init() {
151+
super.init(numberOfWheels: 2)
152+
}
153+
}
154+
155+
class Car: Vehicle {
156+
init() {
157+
super.init(numberOfWheels: 4)
158+
}
159+
}
160+
```
161+
162+
could be refactored into these definitions:
163+
164+
```swift
165+
protocol Vehicle {
166+
var numberOfWheels: Int { get }
167+
}
168+
169+
func maximumTotalTirePressure(vehicle: Vehicle, pressurePerWheel: Float) -> Float {
170+
return pressurePerWheel * vehicle.numberOfWheels
171+
}
172+
173+
struct Bicycle: Vehicle {
174+
let numberOfWheels = 2
175+
}
176+
177+
struct Car: Vehicle {
178+
let numberOfWheels = 4
179+
}
180+
```
181+
182+
_Rationale:_ Value types are simpler, easier to reason about, and behave as expected with the `let` keyword.
183+
128184
#### Make as much of a class `final` as possible

0 commit comments

Comments
 (0)
0