|
1 | | -# iOS-Coding-Style-Guide |
2 | | -iOS Coding Style Guide |
| 1 | +# Introduction |
| 2 | +This style guide outlines the common coding conventions of the iOS Developers. |
| 3 | + |
| 4 | +# Table of Contents |
| 5 | +* [Spacing](#spacing) |
| 6 | +* [Comments](#comments) |
| 7 | + |
| 8 | +# Spacing |
| 9 | +* Indent must use 4 spaces. Be sure to set this preference in Xcode (defaults is 4 spaces). |
| 10 | +* Method braces and other braces (if/else/switch/while etc.) must open on the same line as the statement. Braces must close on a new line. |
| 11 | + |
| 12 | + **For example: Objective-c** |
| 13 | + ```obj-c |
| 14 | + if (user.isHappy) { |
| 15 | + // Do something |
| 16 | + } |
| 17 | + else { |
| 18 | + // Do something else |
| 19 | + } |
| 20 | + ``` |
| 21 | + |
| 22 | + **Swift** |
| 23 | + ```swift |
| 24 | + if user.isHappy == true { |
| 25 | + // Do something |
| 26 | + } |
| 27 | + else { |
| 28 | + // Do something else |
| 29 | + } |
| 30 | + ``` |
| 31 | +* Separate imports from the rest of your file by 1 space. Optionally group imports if there are many (but try to have less dependencies). Include frameworks first. |
| 32 | + |
| 33 | + **For example: Objective-c** |
| 34 | + ```obj-c |
| 35 | + #import <AwesomeFramework/AwesomeFramework.h> |
| 36 | + #import <AnotherFramework/AnotherFramework.h> |
| 37 | + |
| 38 | + #import "SomeDependency.h" |
| 39 | + #import "SomeOtherDependency.h" |
| 40 | + |
| 41 | + @interface MyClass |
| 42 | + ``` |
| 43 | + |
| 44 | + **Swift** |
| 45 | + ```swift |
| 46 | + import AwesomeFramework |
| 47 | + import AnotherFramework |
| 48 | + |
| 49 | + class MyViewController: UIViewController { |
| 50 | + // class stuff here |
| 51 | + } |
| 52 | + ``` |
| 53 | + |
| 54 | +* In Objective-C, use one empty line between class extension and implementation in .m file. |
| 55 | + |
| 56 | + ``` obj-c |
| 57 | + @interface MyClass() |
| 58 | + |
| 59 | + // Properties - empty line above and below |
| 60 | + |
| 61 | + @end |
| 62 | + |
| 63 | + @implementation MyClass |
| 64 | + |
| 65 | + // Body - empty line above and below |
| 66 | + |
| 67 | + @end |
| 68 | + ``` |
| 69 | + |
| 70 | +* When using pragma marks leave 1 newline before and after. |
| 71 | + |
| 72 | + **For example: Objective-c** |
| 73 | + ``` obj-c |
| 74 | + - (void)awakeFromNib { |
| 75 | + [super awakeFromNib]; |
| 76 | + // something |
| 77 | + } |
| 78 | + |
| 79 | + #pragma mark - Config Cell |
| 80 | + |
| 81 | + - (void)configCell { |
| 82 | + // something |
| 83 | + } |
| 84 | + ``` |
| 85 | + |
| 86 | + **Swift** |
| 87 | + ```swift |
| 88 | + override func awakeFromNib() { |
| 89 | + super.awakeFromNib() |
| 90 | + // somthing |
| 91 | + } |
| 92 | + |
| 93 | + // MARK: - Config Cell |
| 94 | + |
| 95 | + func configCell() { |
| 96 | + //something |
| 97 | + } |
| 98 | + ``` |
| 99 | +* Prefer using auto-synthesis. But if necessary, `@synthesize` and `@dynamic` must each be declared on new lines in the implementation. |
| 100 | +* There should be exactly one blank line between methods to aid in visual clarity and organization. |
| 101 | +* Whitespace within methods should separate functionality, but often there should probably be new methods. |
| 102 | +* When doing math use a single space between operators. Unless that operator is unary in which case don't use a space. |
| 103 | + **For example:** |
| 104 | + ```obj-c |
| 105 | + index = index + 1; |
| 106 | + index++; |
| 107 | + index += 1; |
| 108 | + index--; |
| 109 | + ``` |
| 110 | +* Colon-aligning method invocation should often be avoided. There are cases where a method signature may have >= 3 colons and colon-aligning makes the code more readable. Please do NOT however colon align methods containing blocks because Xcode's indenting makes it illegible. |
| 111 | + |
| 112 | + **Good:** |
| 113 | + |
| 114 | + **objective-c** |
| 115 | + ```obj-c |
| 116 | + // blocks are easily readable |
| 117 | + [UIView animateWithDuration:1.0 animations:^{ |
| 118 | + // something |
| 119 | + } completion:^(BOOL finished) { |
| 120 | + // something |
| 121 | + }]; |
| 122 | + ``` |
| 123 | + |
| 124 | + **swift** |
| 125 | + ```swift |
| 126 | + UIView.animate(withDuration: 1.0, animations: { |
| 127 | + // something |
| 128 | + }, completion: { finished in |
| 129 | + // somthing |
| 130 | + }) |
| 131 | + |
| 132 | + ``` |
| 133 | + |
| 134 | + |
| 135 | + **Bad:** |
| 136 | + |
| 137 | + **objective-c** |
| 138 | + |
| 139 | + ```obj-c |
| 140 | + // colon-aligning makes the block indentation wacky and hard to read |
| 141 | + [UIView animateWithDuration:1.0 |
| 142 | + animations:^{ |
| 143 | + // something |
| 144 | + } |
| 145 | + completion:^(BOOL finished) { |
| 146 | + // something |
| 147 | + }]; |
| 148 | + ``` |
| 149 | + |
| 150 | + **swift** |
| 151 | + ```swift |
| 152 | + UIView.animate(withDuration: 1.0, |
| 153 | + animations: { |
| 154 | + // something |
| 155 | + }, completion: { finished in |
| 156 | + // somthing |
| 157 | + }) |
| 158 | + ``` |
| 159 | + |
| 160 | +# Comments |
| 161 | +* When they are needed, comments should be used to explain why a particular piece of code does something. Any comments that are used must be kept up-to-date or deleted. |
| 162 | +* Avoid block comments inline with code, as the code should be as self-documenting as possible. Exception: This does not apply to those comments used to generate documentation. |
| 163 | + |
| 164 | +Developing.... |
| 165 | + |
| 166 | + |
| 167 | +# References |
| 168 | +- [raywenderlich.com Objective-C style guide](https://github.com/raywenderlich/objective-c-style-guide) |
| 169 | +- [NYTimes Objective-C style guide](https://github.com/NYTimes/objective-c-style-guide) |
| 170 | +- [Robots and Pencils Objective-C style guide](https://github.com/RobotsAndPencils/objective-c-style-guide#comments) |
0 commit comments