You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should make our access control annotations (private, private(set), or not) and our mutability annotations (let vs var) as strict as possible.
Why?
Cognitive load: These annotations are not only for the compiler; they make it easier to reason about what ought or ought not to happen. They help coders accurately describe data, data flows, and user flows according to Product requirements, and they help current coders prevent future bugs.
Compiler optimization: If the compiler knows something is immutable, it can optimize for faster execution.
For access controls, coders should ask themselves with each API (property, function, class, etc): Do outsiders need to have access to this information or this function ("need to know" principle)? If not, it should be marked private (or sometimes fileprivate as the case may be). Or maybe outsiders need only read access and not write access (private(set)).
In short:
If it could be private, it should be private.
If it could be immutable, it should be immutable.
The text was updated successfully, but these errors were encountered:
We should make our access control annotations (private, private(set), or not) and our mutability annotations (let vs var) as strict as possible.
Why?
For access controls, coders should ask themselves with each API (property, function, class, etc): Do outsiders need to have access to this information or this function ("need to know" principle)? If not, it should be marked
private
(or sometimesfileprivate
as the case may be). Or maybe outsiders need only read access and not write access (private(set)
).In short:
private
, it should beprivate
.The text was updated successfully, but these errors were encountered: