Skip to content

Instantly share code, notes, and snippets.

@erica
Last active December 11, 2018 01:05

Revisions

  1. erica revised this gist Dec 11, 2018. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -14,4 +14,4 @@
    * 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}
    * Don't fear uppercase. Use TitleCase for types and enum variants.

    _Thanks, [Kevin Ballard](http://twitter.com/Eridius)_
    _Thanks, [Lily Ballard](http://twitter.com/LilyInTech)_
  2. erica revised this gist May 5, 2015. 1 changed file with 3 additions and 1 deletion.
    4 changes: 3 additions & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -12,4 +12,6 @@
    * Don't avoid Foundation and Cocoa. At the same time, use Swift native types whenever possible.
    * Don't use `CGPointMake()`. 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}
    * Don't fear uppercase. Use TitleCase for types and enum variants.
    * Don't fear uppercase. Use TitleCase for types and enum variants.

    _Thanks, [Kevin Ballard](http://twitter.com/Eridius)_
  3. erica revised this gist May 5, 2015. No changes.
  4. erica revised this gist May 5, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -12,4 +12,4 @@
    * Don't avoid Foundation and Cocoa. At the same time, use Swift native types whenever possible.
    * Don't use `CGPointMake()`. 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}
    * Don't fear uppercase. Use TitleCase for types and enums.
    * Don't fear uppercase. Use TitleCase for types and enum variants.
  5. erica revised this gist May 5, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -12,4 +12,4 @@
    * Don't avoid Foundation and Cocoa. At the same time, use Swift native types whenever possible.
    * Don't use `CGPointMake()`. 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}
    * Don't fear uppercase. Consider using uppercase initial letters for symbols defined at the global scope. (This is an ongoing discussion. See [here](https://devforums.apple.com/thread/270081?tstart=0)).
    * Don't fear uppercase. Use TitleCase for types and enums.
  6. erica revised this gist May 5, 2015. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -7,8 +7,8 @@
    * Don't use classes when structs will do. Use classes if you want reference types. Use structs if you want value types. You can add functionality to both (and to enumerations) in Swift. When in doubt, err on the side of value types. 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. Access controls ensure your code can be re-used and modularized.
    * Don't be unnecessarily verbose. Use inferred `get` clauses (for properties), anonymous arguments (e.g. $0, skipping the type in bits for closures), etc to clean up your code.con
    * Don't use Allman. 1TBS is your Swift style.
    * Don't be unnecessarily verbose. Use inferred `get` clauses (for properties), anonymous arguments (e.g. $0, skipping the type in bits for closures), etc to clean up your code.
    * Don't use [Allman](http://en.wikipedia.org/wiki/Indent_style#Allman_style). [http://en.wikipedia.org/wiki/Indent_style#Variant:_1TBS](1TBS) is your Swift style.
    * Don't avoid Foundation and Cocoa. At the same time, use Swift native types whenever possible.
    * Don't use `CGPointMake()`. 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}
  7. erica revised this gist May 5, 2015. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -3,13 +3,13 @@
    * Don't add code cruft. Avoid parentheses around conditions in if-statements or with the `return` keyword. Don't add semicolons except where syntactically demanded in statements or to separate statements on the same line.
    * 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, especially for properties. The compiler better optimizes let statements for items whose values will not change during their lifetime. For example, [Apple writes](https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/CollectionTypes.html), "It is good practice to create immutable collections in all cases where the collection does not need to change. Doing so enables the Swift compiler to optimize the performance of the collections you create."
    * Don't use `var` when `let` is appropriate, especially for properties. The compiler better optimizes `let` statements for items whose values will not change during their lifetime. For example, [Apple writes](https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/CollectionTypes.html), "It is good practice to create immutable collections in all cases where the collection does not need to change. Doing so enables the Swift compiler to optimize the performance of the collections you create."
    * Don't use classes when structs will do. Use classes if you want reference types. Use structs if you want value types. You can add functionality to both (and to enumerations) in Swift. When in doubt, err on the side of value types. 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. Access controls ensure your code can be re-used and modularized.
    * Don't be unnecessarily verbose. Use inferred `get` clauses (for properties), anonymous arguments (e.g. $0, skipping the type in bits for closures), etc to clean up your code.con
    * Don't use Allman. 1TBS is your Swift style.
    * Don't avoid Foundation and Cocoa. At the same time, use Swift native types whenever possible.
    * Don't use CGRectMake(). Prefer Swift constructors and initializers over legacy ones.
    * Don't use `CGPointMake()`. 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}
    * Don't fear uppercase. Consider using uppercase initial letters for symbols defined at the global scope. (This is an ongoing discussion. See [here](https://devforums.apple.com/thread/270081?tstart=0)).
  8. erica revised this gist May 5, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -12,4 +12,4 @@
    * Don't avoid Foundation and Cocoa. At the same time, 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}
    * Don't fear uppercase. Use uppercase initial letters for symbols defined at the global scope. (This is an ongoing discussion. See [here](https://devforums.apple.com/thread/270081?tstart=0)).
    * Don't fear uppercase. Consider using uppercase initial letters for symbols defined at the global scope. (This is an ongoing discussion. See [here](https://devforums.apple.com/thread/270081?tstart=0)).
  9. erica revised this gist May 5, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -12,4 +12,4 @@
    * Don't avoid Foundation and Cocoa. At the same time, 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}
    * Don't fear uppercase. Use uppercase initial letters for symbols
    * Don't fear uppercase. Use uppercase initial letters for symbols defined at the global scope. (This is an ongoing discussion. See [here](https://devforums.apple.com/thread/270081?tstart=0)).
  10. erica revised this gist May 5, 2015. 1 changed file with 2 additions and 1 deletion.
    3 changes: 2 additions & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -3,7 +3,7 @@
    * Don't add code cruft. Avoid parentheses around conditions in if-statements or with the `return` keyword. Don't add semicolons except where syntactically demanded in statements or to separate statements on the same line.
    * 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, especially for properties. The compiler better optimizes let statements for items whose values will not change during their lifetime. For example, Apple writes, "It is good practice to create immutable collections in all cases where the collection does not need to change. Doing so enables the Swift compiler to optimize the performance of the collections you create."
    * Don't use var when let is appropriate, especially for properties. The compiler better optimizes let statements for items whose values will not change during their lifetime. For example, [Apple writes](https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/CollectionTypes.html), "It is good practice to create immutable collections in all cases where the collection does not need to change. Doing so enables the Swift compiler to optimize the performance of the collections you create."
    * Don't use classes when structs will do. Use classes if you want reference types. Use structs if you want value types. You can add functionality to both (and to enumerations) in Swift. When in doubt, err on the side of value types. 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. Access controls ensure your code can be re-used and modularized.
    @@ -12,3 +12,4 @@
    * Don't avoid Foundation and Cocoa. At the same time, 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}
    * Don't fear uppercase. Use uppercase initial letters for symbols
  11. erica revised this gist May 5, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -7,7 +7,7 @@
    * Don't use classes when structs will do. Use classes if you want reference types. Use structs if you want value types. You can add functionality to both (and to enumerations) in Swift. When in doubt, err on the side of value types. 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. Access controls ensure your code can be re-used and modularized.
    * Don't avoid concision. Use inferred get clauses (for properties), anonymous arguments (e.g. $0, skipping the type in bits for closures), etc to clean up your code.
    * Don't be unnecessarily verbose. Use inferred `get` clauses (for properties), anonymous arguments (e.g. $0, skipping the type in bits for closures), etc to clean up your code.con
    * Don't use Allman. 1TBS is your Swift style.
    * Don't avoid Foundation and Cocoa. At the same time, use Swift native types whenever possible.
    * Don't use CGRectMake(). Prefer Swift constructors and initializers over legacy ones.
  12. erica revised this gist May 5, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -3,7 +3,7 @@
    * Don't add code cruft. Avoid parentheses around conditions in if-statements or with the `return` keyword. Don't add semicolons except where syntactically demanded in statements or to separate statements on the same line.
    * 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. For example, Apple writes, "It is good practice to create immutable collections in all cases where the collection does not need to change. Doing so enables the Swift compiler to optimize the performance of the collections you create."
    * Don't use var when let is appropriate, especially for properties. The compiler better optimizes let statements for items whose values will not change during their lifetime. For example, Apple writes, "It is good practice to create immutable collections in all cases where the collection does not need to change. Doing so enables the Swift compiler to optimize the performance of the collections you create."
    * Don't use classes when structs will do. Use classes if you want reference types. Use structs if you want value types. You can add functionality to both (and to enumerations) in Swift. When in doubt, err on the side of value types. 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. Access controls ensure your code can be re-used and modularized.
  13. erica revised this gist May 5, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -4,7 +4,7 @@
    * 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. For example, Apple writes, "It is good practice to create immutable collections in all cases where the collection does not need to change. Doing so enables the Swift compiler to optimize the performance of the collections you create."
    * 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 classes when structs will do. Use classes if you want reference types. Use structs if you want value types. You can add functionality to both (and to enumerations) in Swift. When in doubt, err on the side of value types. 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. Access controls ensure your code can be re-used and modularized.
    * Don't avoid concision. Use inferred get clauses (for properties), anonymous arguments (e.g. $0, skipping the type in bits for closures), etc to clean up your code.
  14. erica revised this gist May 5, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -3,7 +3,7 @@
    * Don't add code cruft. Avoid parentheses around conditions in if-statements or with the `return` keyword. Don't add semicolons except where syntactically demanded in statements or to separate statements on the same line.
    * 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 var when let is appropriate. The compiler better optimizes let statements for items whose values will not change during their lifetime. For example, Apple writes, "It is good practice to create immutable collections in all cases where the collection does not need to change. Doing so enables the Swift compiler to optimize the performance of the collections you create."
    * 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. Access controls ensure your code can be re-used and modularized.
  15. erica revised this gist May 5, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -1,6 +1,6 @@
    ### 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 add code cruft. Avoid parentheses around conditions in if-statements or with the `return` keyword. Don't add semicolons except where syntactically demanded in statements or to separate statements on the same line.
    * 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.
  16. erica revised this gist May 5, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -9,6 +9,6 @@
    * Don't forget access controls, especially for top-level definitions. Access controls ensure your code can be re-used and modularized.
    * Don't avoid concision. Use inferred get clauses (for properties), anonymous arguments (e.g. $0, skipping the type in bits for closures), 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 avoid Foundation and Cocoa. At the same time, 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}
  17. erica revised this gist May 5, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -7,7 +7,7 @@
    * 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. Access controls ensure your code can be re-used and modularized.
    * Don't avoid concision. Use inferred get clauses, anonymous arguments, etc to clean up your code.
    * Don't avoid concision. Use inferred get clauses (for properties), anonymous arguments (e.g. $0, skipping the type in bits for closures), 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.
  18. erica revised this gist May 5, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -7,7 +7,7 @@
    * 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. Access controls ensure your code can be re-used and modularized.
    * Don't be afraid of concision. Use inferred get clauses, anonymous arguments, etc to clean up your code.
    * Don't avoid 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.
  19. erica revised this gist May 5, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -6,7 +6,7 @@
    * 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 forget access controls, especially for top-level definitions. Access controls ensure your code can be re-used and modularized.
    * 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.
  20. erica revised this gist May 5, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -5,7 +5,7 @@
    * 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.
    * 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.
  21. erica revised this gist May 5, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -4,7 +4,7 @@
    * 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 class when struct will do. If your construct doesn't have a life cycle, or two construct with similar values should be considered as the same thing, use a struct.
    * 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.
    * 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.
  22. erica revised this gist May 5, 2015. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -2,8 +2,8 @@

    * 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.
    * 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 class when struct will do. If your construct doesn't have a life cycle, or two construct 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.
    * Don't forget access controls, especially for top-level definitions.
  23. erica revised this gist May 5, 2015. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -2,7 +2,7 @@

    * 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 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.
    * Don't use class when struct will do. If your construct doesn't have a life cycle, or two construct 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.
  24. erica revised this gist May 5, 2015. 1 changed file with 1 addition and 2 deletions.
    3 changes: 1 addition & 2 deletions gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -1,7 +1,6 @@
    ### Swift Don'ts

    * Don't add parentheses around conditions in if-statements
    * Don't add semicolons except where syntactically demanded in statements or to separate statements on the same line
    * 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.
  25. erica created this gist May 5, 2015.
    15 changes: 15 additions & 0 deletions gistfile1.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,15 @@
    ### Swift Don'ts

    * Don't add parentheses around conditions in if-statements
    * Don't add semicolons except where syntactically demanded in statements or to separate statements on the same line
    * 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.
    * Don't use class when struct will do. If your construct doesn't have a life cycle, or two construct 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.
    * 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}