IOS Team Programming Standards

[[201429]]

Preface

Demand is temporary, only change is eternal. Program for change, not for demand.

Don't pursue too much skills and reduce the readability of the program.

Clean code leaves no room for bugs to hide. Write code that is obviously bug-free, not code without obvious bugs.

Solve the current problem first, and then consider future expansion issues.

1. Naming conventions

1. Unified requirements

The meaning should be clear, and its function should be understood without comments. If this is not possible, add comments, use full names instead of abbreviations.

2. Class Name

CamelCase: The first letter of each word is capitalized

==Example:== MFHomePageViewController

3. Private variables

• Private variables are declared in the .m file
• Start with _, the first letter of the first word is lowercase, and the first letters of the following words are all uppercase.

==Example:== NSString *_somePrivateVariable

4. Property variables

• CamelCase: The first word starts with a lowercase letter, and the first letter of the following words is all capitalized.
• It is recommended that the attribute keywords be arranged in the order of atomicity, read/write, and memory management.
• Block and NSString attributes should use the copy keyword
• The synthesize keyword is not allowed

==Example:==

 typedef void (^ErrorCodeBlock) (id errorCode,NSString *message); 
 
 @property (nonatomic, readwrite, strong) UIView *headerView; //Comments 
 
 @property (nonatomic, readwrite, copy) ErrorCodeBlock errorBlock; //Copy the block to the heap 
 
 @property (nonatomic, readwrite, copy) NSString *userName;

5. Macro and constant naming

• For macro-defined constants

#define preprocessor defined constants are all uppercase, with words separated by _

If a macro definition contains expressions or variables, the expressions or variables must be enclosed in parentheses.

• For type constants

For constants that are limited to a certain compilation unit (implementation file), they start with the character k, such as kAnimationDuration, and need to be modified with static const.

For constants defined in the class header file, which are visible externally, they start with the class name of the class in which the constant is defined. For example, EOCViewClassAnimationDuration follows Apple's style, with an extern declaration in the header file and its value defined in the implementation file.

==Example:==

 //Macro defined constants 
 
 #define ANIMATION_DURATION 0.3 
 
 #define MY_MIN(A, B) ((A)>(B)?(B):(A)) 
 
  
 
 //Local type constants 
 
 static const NSTimeInterval kAnimationDuration = 0.3; 
 
  
 
 //Externally visible type constants 
 
 //EOCViewClass.h 
 
 extern const NSTimeInterval EOCViewClassAnimationDuration; 
 
 extern NSString *const EOCViewClassStringConstant; //string type 
 
  
 
 //EOCViewClass.m 
 
 const NSTimeInterval EOCViewClassAnimationDuration = 0.3; 
 
 NSString *const EOCViewClassStringConstant = @ "EOCStringConstant" ;

6. Enum

• The naming convention of Enum type is consistent with that of class.
• The name of the enumeration content in Enum must start with the name of the Enum type.
• NS_ENUM defines general enumeration, NS_OPTIONS defines displacement enumeration

==Example:==

 typedef NS_ENUM(NSInteger, UIViewAnimationTransition) { 
 
    UIViewAnimationTransitionNone, 
 
    UIViewAnimationTransitionFlipFromLeft, 
 
    UIViewAnimationTransitionFlipFromRight, 
 
    UIViewAnimationTransitionCurlUp, 
 
    UIViewAnimationTransitionCurlDown, 
 
 }; 
 
  
 
 typedef NS_OPTIONS(NSUInteger, UIControlState) { 
 
    UIControlStateNormal = 0, 
 
    UIControlStateHighlighted = 1

7. Delegate

• Use delegate as suffix, such as
• Use optional to modify methods that may not be implemented, and use required to modify methods that must be implemented
• When your delegate has too many methods, you can split the data part and other logic parts, and use dataSource as the suffix for the data part.
• Use did and will to notify the delegate of changes that have occurred or are about to occur.
• An instance of the class must be one of the parameters of the callback method
• The callback method has only the class's own parameters, and the method name must be consistent with the actual meaning
• If there are more than two parameters in the callback method, it starts with the class name to indicate which class the method belongs to.

==Example:==

 @protocolUITableViewDataSource    
 
 @required   
 
 //The callback method has more than two parameters 
 
 - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger) section ;   
 
 @optional 
  
 
 //The callback method only has the class itself as a parameter 
 
 - (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView; // Default   is 1 if not implemented 
 
 
 @protocol UITableViewDelegate    
 
 @optional 
  
 
 //Use `did` and `will` to notify `Delegate` 
 
 - (nullable NSIndexPath *)tableView:(UITableView *)tableView willSelectRowAtIndexPath:(NSIndexPath *)indexPath; 
 
 - (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath;

8. Methods

• Method names are named in lower camel case
• Do not use new as the prefix for method names.
• Do not use and to connect attribute parameters. If the method describes two independent behaviors, use and to concatenate them.
• When implementing a method, if the parameters are too long, make each parameter occupy one line and align them with colons.
• General methods do not use prefixes for naming, private methods can use a unified prefix to group and identify
• The method name should be highly consistent with the corresponding parameter name
• Methods that express object behavior and executable methods should begin with a verb
• Returning methods should start with the return value, but do not add get before it unless they are indirectly returning one or more values.
• You can use modal verbs (can, should, will, etc.) to further explain the meaning of the attribute, but do not use do or does, because these auxiliary verbs have no practical meaning. Also, do not use adverbs or adjectives before the verb to modify the attribute.

==Example:==

 //Do not use and to connect attribute parameters 
 
 - ( int )runModalForDirectory:(NSString *)path file:(NSString *) name types:(NSArray *)fileTypes; //Recommended 
 
 - ( int )runModalForDirectory:(NSString *)path andFile:(NSString *) name andTypes:(NSArray *)fileTypes; //Objection  
  
 
 //Methods that represent object behavior and execution methods 
 
 - (void)insertModel:(id)model atIndex:(NSUInteger)atIndex; 
 
 - (void)selectTabViewItem:(NSTableViewItem *)tableViewItem  
  
 
 //Returning method 
 
 - (instancetype)arrayWithArray:(NSArray *)array;  
  
 
 // Parameters are too long 
 
 - (void)longMethodWith:(NSString *)theFoo  
                  rect:(CGRect)theRect  
              interval:(CGFloat)theInterval  
 {  
 //Implementation  
 }    
 
 //Don't add get  
 - (NSSize) cellSize; //Recommended  
 - (NSSize) getCellSize; //Oppose   
 
 //Use modal verbs, don't use do or does  
 - (BOOL)canHide; //Recommend  
 - (BOOL)shouldCloseDocument; //Recommended  
 - (BOOL)doesAcceptGlyphInfo; //Oppose

2. Code Comment Standards

Most excellent code is self-describing. We can use the code itself to express what it is doing without the help of comments.

But it does not mean that you must not write comments. There are three situations where comments are more suitable:

• Public interface (comments should tell people who read the code what functions the current class can achieve).
• Code involving relatively deep professional knowledge (comments should reflect the implementation principles and ideas).
• Code that is prone to ambiguity (but strictly speaking, code that is prone to ambiguity is not allowed to exist).

In addition to the above three situations, if others can only understand your code through comments, you should reflect on what problems the code has.

***, for the content of the comment, it is more important to explain "why it is done" rather than "what is done".

1. Import comments

If there is more than one import statement, the statements are grouped together, with an optional comment for each group.

 // Frameworks  
 #import ;  
 // Models  
 #import "NYTUser.h"    
 // Views  
 #import "NYTButton.h"    
 #import "NYTUserView.h"  

2. Attribute Annotation

Write after the attribute, separated by two spaces

==Example:==

 @property (nonatomic, readwrite, strong) UIView *headerView; //Comments

3. Method declaration comments:

A function (method) must have a documentation string explaining its use, unless it:

• Non-public, private functions.
• Very short.
• It's obvious.

The rest, including public interfaces, important methods, classes, and protocols, should be accompanied by documentation (comments):

• Starts with /
• The second line is a summary statement
• The third line is always blank.
• Write the rest of the comment aligned with the beginning of the second line.

It is recommended to write:

 /This comment serves to demonstrate the format of a doc string. 
 
  
 
 Note that the summary line is always at most one line long, and   after the opening block comment, 
 
 and each line of text is preceded by a single space . 
 
 */

Method comments use Xcode's built-in comment shortcut: Commond+option+/

==Example:==

 /** 
 
  
 
 @param tableView 
 
 @param section   
 
 <a href= 'http://www.jobbole.com/members/wx1409399284' > @ return </a> 
 
 */ 
 
 - (CGFloat)tableView:(UITableView *)tableView heightForHeaderInSection:(NSInteger) section   
 
 { 
 
 //... 
 
 }

4. Code block comments

Single-line comments start with //+space, multi-line comments start with /* */

5. TODO

Use //TODO: to mark unfinished or unsatisfactory areas.

==Example:==

 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions 
 
 { 
 
 //TODO: Add initialization 
 
 return YES; 
 
 }

3. Code formatting specifications

1. Pointer* position

When defining an object, the pointer* is placed next to the variable

==Example:== NSString *userName;

2. Method declaration and definition

Leave a space between -, + and the return value, and no space between the method name and the first parameter.

==Example:==

 - (void)insertSubview:(UIView *) view atIndex:(NSInteger) index ;

3. Code indentation

• Do not use the Tab key in your project, use spaces for indentation. Set both Tab and Auto-indent to 4 spaces in Xcode > Preferences > Text Editing
• There is a blank line between Method and Method.
• There is no space between unary operators and variables, and there must be a space between binary operators and variables.

==Example:==

 !bValue 
 
 fLength = fWidth * 2;   
 
 - (void)sampleMethod1;   
 
 - (void)sampleMethod2;

4. Group methods

Use #pragma mark - to group methods

 #pragma mark - Life Cycle Methods 
 
 - (instancetype)init 
 
 - (void)dealloc   
 
 - (void)viewWillAppear:(BOOL)animated 
 
 - (void)viewDidAppear:(BOOL)animated 
 
 - (void)viewWillDisappear:(BOOL)animated 
 
 - (void)viewDidDisappear:(BOOL)animated   
 
 #pragma mark - Override Methods 
 
 #pragma mark - Initial Methods   
 
 #pragma mark - Network Methods   
 
 #pragma mark - Target Methods  
 
 #pragma mark - Public Methods   
 
 #pragma mark - Private Methods   
 
 #pragma mark - UITableViewDataSource 
 
 #pragma mark-UITableViewDelegate   
 
 #pragma mark - Lazy Loads  
 
 #pragma mark - NSCopying  
 
 #pragma mark - NSObject Methods

5. Braces writing

For class methods: write the left bracket on a separate line (follow Apple's official documentation)

For other usage scenarios (if, for, while, switch, etc.): The left bracket follows the first line

==Example:==

 - (void)sampleMethod 
 
 { 
 
 BOOL someCondition = YES; 
 
 if(someCondition) { 
 
 // do something here 
 
 } 
 
 }

6. Property variables

==Example:==

 @property (nonatomic, readwrite, strong) UIView *headerView; //Comments

4. Coding Standards

1. If statement

① All branches must be listed (exhaustively enumerate all situations), and each branch must give a clear result.

==It is recommended to write like this:==

 var hintStr; 
 
 if ( count < 3) { 
 
 hintStr = "Good" ; 
 
 } else { 
 
 hintStr = "" ; 
 
 }

==It is not recommended to write like this:==

 var hintStr; 
 
 if ( count < 3) { 
 
 hintStr = "Good" ; 
 
 }

②. Do not use too many branches. Be good at using return to return to the error situation in advance and put the most correct situation at the last return.

==It is recommended to write like this:==

 if (! user .UserName) return   NO ; 
 
 if (! user . Password ) return   NO ; 
 
 if (! user.Email ) return   NO ;   
 
 return YES;

==It is not recommended to write like this:==

 BOOL isValid = NO ; 
 
 if ( user .UserName) 
 
 {
 if ( user . Password )
 {
        if ( user .Email) isValid = YES;
 }
 }
 return isValid;

③. If there are too many conditions, they should be wrapped if they are too long. If the conditional expression is very long, you need to extract them and assign them to a BOOL value, or extract a method

==It is recommended to write like this:==

 if (condition1 && 
 
 condition2 && 
 
 condition3 && 
 
 condition4) { 
 
 // Do something 
 
 }

 BOOL finalCondition = condition1 && condition2 && condition3 && condition4 
 
 if (finalCondition) { 
 
 // Do something 
 
 } 
 
 
 if ([self canDelete]){ 
 
 // Do something 
 
 } 
 
  
 
 - (BOOL)canDelete 
 
 { 
 
    BOOL finalCondition1 = condition1 && condition2 
 
    BOOL finalCondition2 = condition3 && condition4 
 
  
 
 return condition1 && condition2; 
 
 }

==It is not recommended to write like this:==

 if (condition1 && condition2 && condition3 && condition4) { 
 
 // Do something 
 
 }

④. The judgment of the conditional statement should be that the variable is on the right and the constant is on the left.

==Recommendation:==

 if (6 == count ) { 
 
 }   
 
 if (nil == object) { 
 
 }   
 
 if (!object) { 
 
 }

==Not recommended:==

 if ( count == 6) { 
 
 } 
 
 if (object == nil) { 
 
 }

if (object == nil) is easily mistaken for an assignment statement, while if (!object) is much simpler.

⑤. The implementation code of each branch must be surrounded by curly braces

==Recommendation:==

 if (!error) { 
 
 return success; 
 
 }

==Not recommended:==

 if (!error)
 return success;

This can be written as follows:

 if (!error) return success;

2. for statement

①. Do not modify the loop variable in the for loop to prevent the for loop from getting out of control.

 for ( int   index = 0; index < 10; index ++){
 ...
 logicToChange( index )
 }

②. Avoid using continue and break.

Continue and break describe "when not to do something", so in order to understand the code where they are located, we need to reverse them in our minds.

In fact, it is best not to let these two things appear, because our code only needs to reflect "what to do when", and these two things can be eliminated through appropriate methods:

• If continue occurs, just negate the continue condition.

 var filteredProducts = Array()
 for   level   in products {
    if level .hasPrefix( "bad" ) {
 continue  
 }
    filteredProducts.append( level )
 }

We can see that some values ​​are filtered out by judging whether the string contains the prefix "bad". In fact, we can avoid using continue by negating it:

 for   level   in products {  
    if ! level .hasPrefix( "bad" ) {  
      filteredProducts.append( level )  
 }  
 }

• Eliminate the break in while: negate the break condition and merge it into the main loop

The break in while is actually equivalent to "does not exist". Since it is something that does not exist, it can be completely excluded in the initial conditional statement.

break in while:

 while (condition1) {
 ...
 if (condition2) {
 break;
 }
 }

Negate and merge into the main condition:

 while (condition1 && !condition2) {
 ...
 }

• Eliminate break in methods with return values: convert break to return immediately

Some people like to do this: return a value after breaking in a method that returns a value. In fact, you can return directly on the line where you break.

 func hasBadProductIn(products: Array) -> Bool {
 var result = false      
 for   level   in products {
        if level .hasPrefix( "bad" ) {
 result = true  
 break
 }
 }
 return result
 }

Return directly if an error condition is encountered:

 func hasBadProductIn(products: Array) -> Bool { 
 
 for   level   in products { 
 
        if level .hasPrefix( "bad" ) { 
 
 return   true   
 
 } 
 
 } 
 
 return   false   
 
 }

Written in this way, there is no need to declare a variable specifically to save the value to be returned. It looks very concise and highly readable.

3. Switch Statement

① Each branch must be enclosed in curly braces

It is recommended to write:

 switch ( integer ) {  
 case 1: {  
 // ...  
 }  
 break;  
 case 2: {  
 // ...  
 break;  
 }  
 default :{  
 // ...  
 break;  
 }  
 }

② When using enumeration types, there cannot be a default branch. Except for using enumeration types, there must be a default branch.

 RWTLeftMenuTopItemType menuType = RWTLeftMenuTopItemMain;  
 switch (menuType) {  
 case RWTLeftMenuTopItemMain: {  
 // ...  
 break;  
 }  
 case RWTLeftMenuTopItemShows: {  
 // ...  
 break;  
 }  
 case RWTLeftMenuTopItemSchedule: {  
 // ...  
 break;  
 }  
 }

When using an enumeration type in a Switch statement, if the default branch is used, the compiler will not be able to check new enumeration types in the future.

4. Functions

①. A function only does one thing (single principle)

The responsibilities of each function should be clearly defined (just like a class).

==Recommendation:==

 dataConfiguration()  
 viewConfiguration()

==Not recommended:==

 void dataConfiguration()
 {
 ...
 viewConfiguration()
 }

② For functions (methods) with return values, each branch must have a return value

==Recommendation:==

 int   function ()
 {
 if(condition1){
 return count1
 } else if(condition2){
 return count2
 } else {
 return defaultCount
 }
 }

==Not recommended:==

 int   function ()
 {
 if(condition1){
 return count1
 } else if(condition2){
 return count2
 }
 }

③. Check the correctness and validity of input parameters, and return immediately if the parameters are wrong

==Recommendation:==

 void function(param1,param2)
 {
      if(param1 is unavailable){
 return;
 } 
 
      if(param2 is unavailable){
 return;
 }
 //Do some right thing
 }

④. If there are the same functions in different functions, the same functions should be extracted and separated into another function

The original call:

 void logic() {  
 a();  
 b();  
 if (logic1 condition) {  
 c();  
 } else {  
 d();  
 }  
 }

Extract functions a and b as separate functions

 void basicConfig() {
 a();
 b();
 }
 void logic1() {
 basicConfig();
 c();
 }
 void logic2() {
 basicConfig();
 d();
 }

⑤. Extract the more complex logic inside the function as a separate function

The unclear code in a function (more logical judgments and more lines) can often be extracted to form a new function, and then called from the original place. In this way, you can use meaningful function names instead of comments to increase the readability of the program.

Here is an example of sending an email:

 openEmailSite();
 login();
 writeTitle(title);
 writeContent(content);
 writeReceiver(receiver);
 addAttachment(attachment);
 send();

The middle parts are a bit longer, so we can extract them:

 void writeEmail(title, content,receiver,attachment)
 {
 writeTitle(title);
 writeContent(content);
 writeReceiver(receiver);
 addAttachment(attachment);
 }

Then look at the original code again:

 openEmailSite();
 login();
 writeEmail(title, content,receiver,attachment)
 send();