8000 Merge pull request #3 from github/jspahrsummers-patch-1 · smashcoding/swift-style-guide@a5d2a34 · GitHub
[go: up one dir, main page]

Skip to content

Commit a5d2a34

Browse files
committed
Merge pull request github#3 from github/jspahrsummers-patch-1
When to include access control specifiers
2 parents 334ec03 + 728ce9e commit a5d2a34

File tree

1 file changed

+20
-0
lines changed

1 file changed

+20
-0
lines changed

README.md

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -32,3 +32,23 @@ subscript(index: Int) -> T {
3232
```
3333

3434
_Rationale:_ The intent and meaning of the first version is clear, and results in less code.
35+
36+
#### Always specify access control explicitly for top-level definitions
37+
38+
Top-level functions, types, and variables should always have explicit access control specifiers:
39+
40+
```swift
41+
public var whoopsGlobalState: Int
42+
internal struct TheFez {}
43+
private func doTheThings(things: [Thing]) {}
44+
```
45+
46+
However, definitions within those can leave access control implicit, where appropriate:
47+
48+
```swift
49+
internal struct TheFez {
50+
var owner: Person = Joshaber()
51+
}
52+
```
53+
54+
_Rationale:_ It's rarely appropriate for top-level definitions to be specifically `internal`, and being explicit ensures that careful thought goes into that decision. Within a definition, reusing the same access control specifier is just duplicative, and the default is usually reasonable.

0 commit comments

Comments
 (0)
0