gistfile1.md

Swift Don'ts

• Don't add parentheses around conditions in if-statements or semicolons except where syntactically demanded in statements or to separate statements on the same line. These items add unnecessary code cruft.
• Don't use ALL_CAPS; use camelCase
• Don't fight type inference. Use enumeration prefixes, self-references, and class names (with constructors) only when necessary or to clarify coding intent.
• Don't use var when let is appropriate. The compiler better optimizes let statements for items whose values will not change during their lifetime.
• Don't use classes when structs will do. If your construct doesn't have a life cycle, or two constructs with similar values should be considered as the same thing, use a struct.
• Don't use fallback values when what you really want are optionals. If you're working hard to avoid nil checks, you're doing Swift wrong.
• Don't forget access controls, especially for top-level definitions.
• Don't be afraid of concision. Use inferred get clauses, anonymous arguments, etc to clean up your code.
• Don't use Allman. 1TBS is your Swift style.
• Don't avoid Foundation and Cocoa but use Swift native types whenever possible.
• Don't use CGRectMake(). Prefer Swift constructors and initializers over legacy ones.
• Don't use unnecessary variables. The wildcard expression (_) ignores values during assignments. Use it to skip items that are not referenced in the called scope, e.g. let (status, _) = GetInfo() or for _ in 1...5 {//do something 5 times}