4 ms·
These are my rules of thumb in priority order: 1. Don’t use optionals. 2. If you must use optionals due to technicalities (e.g. IBOutlet, weak reference, etc.
by aaaaaaaaaab 8y ago
These are my rules of thumb in priority order:
1. Don’t use optionals.
2. If you must use optionals due to technicalities (e.g. IBOutlet, weak reference, etc.), make it implicitly-unwrapped.
3. If you can’t make it implicitly unwrapped due to ‘nil’ being a legitimate value, then use regular optionals, but force-unwrap it everywhere except where `nil` is expected to occur.
There’s nothing worse than a codebase unnecessarily littered with
guard let x = x else { return }
If my assumptions about some value were wrong, I want it to break as loud as possible. Silently returning (or making up some silly default value like an empty string or zero) is the worst thing you can do for yourself and your colleagues. (Except if you’re a manager whose bonus is tied to your app’s crash stats)
- dkarbayev 8y agoYour approach seems to be a completely wrong use of optionals (have you been writing in Java or any other language with implicit nullability?) since you’re giving up type-safety of Swift. Do you use implicitly unwrapped optionals for delegates too?
- saagarjha 8y agoDelegates should be nil, so it totally makes sense to keep them as an optional. I don’t see this conflicting with the parent’s set of “rules”.
- aaaaaaaaaab 8y ago>since you’re giving up type-safety of Swift Giving up type-safety? Sorry, but I don't understand this in the current context. As for delegates: if the delegate can be 'nil' during normal operations, then it should be a regular optional as per rule #3.