1.7 KiB
1.7 KiB
Annotations and Modifiers
Convention
Method/variable annotations and modifiers should go on the same line as the rest of the definition. i.e.
Rationale
Consistency makes PRs easier to read as well as removing any potential disagreements.
Annotations
// good: On the same line
@objc func doThing() { }
// bad: Not on the same line
@objc
func doThing() { }
There is an exception for when you are renaming for Objective-C. In that case, the annotation may go on the preceeding line. e.g.
@objc(XYThing)
enum Thing: Int {
...
}
The ordering for the annotations follows that of SwiftLint. i.e. @objc
, @nonobjc
, @objcMembers
, @IBAction
, @IBOutlet
, @IBDesignable
, IBInspectable
, @NSManaged
, @NSCopying
Modifiers
Similarly, modifiers should go on the same line and follow SwiftLint conventions for order. e.g.
Regarding the ordering of the annotations, we again follow SwiftLint. i.e. The order should be:
override
- Specify if this is an override or not- Access level (e.g.
private
,public
,open
, etc.) - Setter access level
dynamic
- Specify if dynamic dispatch should be used- Mutators -
mutating
ornonmutating
lazy
- Specify if this declaration is lazy or notfinal
- Specify if this declaration is finalrequired
- Specify if an initializer is required or notconvenience
- Specify if a declaration as convenient or notstatic
- Specify if this is static or notweak
- Specify if the ownership is weak or not