A thoughtful iOS development specification

Preface

Although it is called a preface, it is actually the purpose of this article. With the continuous increase of the company's business and the rapid iteration of functions, the business lines of the app are increasing, and the code volume is becoming larger and larger. At the same time, more and more developers are investing in the app, and the code styles of different developers vary greatly. In addition, the company's developer personnel changes, in order to ensure the stability of the app, ensure development efficiency, and unify the development style. Therefore, this iOS development specification came into being.

Since the development specification of the company where I am currently employed is the main factor in writing, the iteration of the company's business is currently proceeding in an orderly manner according to this specification. Based on the experience of writing specifications before, it took a month to re-sort out a more comprehensive and complete iOS developer specification. I hope that these rules and regulations can provide some reference value for you who are reading. I also hope that more and more iOS developers can develop excellent coding habits. If you think that some places are inappropriate or there are specifications that need to be supplemented, please leave a message or private message, and I will respond as soon as possible.

[[227895]]

Agreement

In my opinion, development specifications are like a standard line for reference. Different developers can regulate their development behaviors according to this standard line. Especially in large projects, development specifications can constrain the development styles of different developers, so that the project can achieve a unified style from details to the whole, which is conducive to maintenance.

The development specifications in this article are composed of many items, and different items describe different problems. Each item is a specific development specification. Violating different development specifications will also cause consequences of different degrees of severity. Just like the difference between law and morality, we must abide by the law, otherwise it may bring serious consequences that harm others and ourselves. However, some people have not violated the law but violated morality. Although there are no serious consequences for the time being, in the long run, it will also form a bad atmosphere. Therefore, regardless of law and morality, we should spur ourselves to become excellent people, and should not stop at being a qualified person. Similarly, the same is true for development specifications. We must abide by those development specifications that must be followed, and advocate compliance with those development specifications that are recommended for you to follow. Therefore, according to the strength of the constraints, we temporarily divide the development specifications into two levels, namely [must] and [recommendation].

1. 【Must】: Must be followed. It is an agreement that must be followed. If violated, it is likely to cause serious consequences.
2. [Suggestion]: It is recommended to comply with this agreement. Long-term compliance with such an agreement will help maintain the stability of the system and improve cooperation efficiency.

This article refers to Apple's official coding guidelines and some well-known coding standards on GitHub. It is an article that takes the best of many and gathers the essence of hundreds of schools. Readers can read selectively according to their actual needs and interests. The main part of this article is mainly composed of the following two chapters (32 sections in total):

(I) Naming conventions

1. General Naming Standards (describes some general naming standards)
2. Abbreviation standards (common abbreviations and abbreviation standards)
3. Method naming conventions (describes the specific conventions for method naming)
4. Accessor naming conventions (describes the naming conventions for set and get methods)
5. Parameter naming conventions (describe parameter naming conventions)
6. Delegate method naming conventions (describes the naming conventions of delegate methods)
7. Private method naming conventions (describes the naming conventions of private methods)
8. Category naming conventions (describes the naming conventions of categories)
9. Class naming conventions (describe class naming conventions)
10. Protocol naming conventions (describes the naming conventions of protocols)
11. Notification naming conventions (describe the naming conventions of notifications)
12. Constant naming conventions (describes the naming conventions for enumeration constants and const constants)
13. Exception naming conventions (describes the naming conventions of exceptions)

(II) Coding Standards

1. Initialize method (describes the usage specifications of the class initialize method)
2. Init method (describes the design specifications of initialization methods, including designated init methods and secondary init methods)
3. Init error (describes error handling when the init method fails to initialize the object)
4. Dealloc specification (describes the usage specifications of the dealloc method)
5. Block specification (describes the usage specifications of blocks)
6. Notification Specifications (describes the usage specifications of notifications)
7. UI specifications (describes some specifications when developing UI)
8. IO specification (some precautions when reading and writing files)
9. Collection Specifications (describes the usage specifications of collection types)
10. Branch statement specifications (describes the coding specifications of commonly used branch statements if and switch statements)
11. Object equality standards (describes the commonly used methods for determining object equality)
12. Lazy loading specifications (describes the usage specifications of lazy loading)
13. Multithreading standards (describes some coding standards in a multithreading environment)
14. Memory management specifications (describes common memory management points in the coding process)
15. Delayed Call Specifications (describes precautions when using delayed methods)
16. Comment standards (describes the use of comments in coding)
17. Class design specifications (describes class design specifications)
18. Code organization standards (code organization standards in narrative classes)
19. Project structure specifications (document organization specifications for projects)

(I) Naming standards

According to the description in the Cocoa coding standards, in the past, naming should follow the following basic principles: Clarity, Consistency, No Self Reference.

(1.1) General naming conventions

In general, common naming rules apply to variables, constants, properties, parameters, methods, functions, etc. Of course, there are exceptions, and we will list them one by one below for each case.

[Required] Self-descriptive. The names of attributes/functions/parameters/variables/constants/macro must be self-descriptive. Avoid Chinese pinyin, excessive abbreviations, or meaningless naming.

[Required] Self-reference is prohibited. Attributes/local variables/member variables should not be self-referential. Exceptions include notifications and mask constants (usually those enumeration values ​​that can be bitwise operated on).

In layman's terms, self-reference means adding a suffix of your own type to the end of the variable.

Mask constants, except notifications:

[Required] CamelCase naming. Parameter names, member variables, local variables, and property names must all use camelCase naming starting with a lowercase letter. If the method name starts with a well-known uppercase abbreviation, camelCase naming is not required, such as FTP, WWW, etc.

[Suggestion] Consistency. The naming of attributes/functions/parameters/variables/constants/macros should be contextually or globally consistent. Variables of the same type or with the same function should be named the same or similarly.

Note: Specifically, the names of attributes with the same or similar functions in different files or classes should be the same or similar. The advantage is that it is convenient for later developers to reduce the amount of code to read and improve the speed of understanding the code. For example:

 // count is defined in three collection classes: NSDictionary, NSArray, and NSSet. And the count attributes in these three collection classes all represent the same meaning, that is, the number of objects in the collection.
 @property (readonly) NSUInteger count ;

[Required] Clarity. The naming of attributes/functions/parameters/variables/constants/macros should be clear and concise. If you can't have your cake and eat it too, clarity is more important.

[Suggestion] In general, do not abbreviate or omit words. It is recommended to spell them out even if they are a bit long. Of course, while ensuring readability, objects traversed in a for loop or parameters of certain methods can be abbreviated.

(1.2) Abbreviation standards

Generally, we shouldn't abbreviate names. However, the following are some well-known abbreviations that we can continue to use. In other cases, we should follow the following two abbreviation suggestions:

• Abbreviations that have been in use since the days of the C language, such as alloc and getc, are allowed.
• We can use abbreviations when naming parameters. In other cases, try not to use abbreviations.

We can also use abbreviations commonly used in the computer industry, including but not limited to HTML, URL, RTF, HTTP, TIFF, JPG, PNG, GIF, LZW, ROM, RGB, CMYK, MIDI, and FTP.

(1.3) Method naming convention

[Required] Method names must also use camelCase starting with a lowercase letter. This rule can be ignored if the method name starts with a well-known uppercase abbreviation (such as HTTP).

[Recommendation] Generally, do not use prefixes in method names because they exist in the namespace of a specific class.

[Recommendation] Classes, protocols, functions, constants, enumerations and other globally visible content need to be prefixed with three characters. Apple reserves the right to use any two characters as prefixes. So try not to use two characters as prefixes. Prohibited prefixes include but are not limited to: NS, UI, CG, CF, CA, WK, MK, CI, NC.

[Required] Do not add an underscore "_" before the method. Apple's official website team often adds an underscore "_" before the method. In order to avoid method overwriting and causing unpredictable accidents, do not add an underscore before the method.

[Must] Self-descriptive. Method names should also be self-descriptive. Avoid Chinese pinyin, excessive abbreviations, or meaningless naming.

[Suggestion] Consistency. Method naming should also be contextually or globally consistent. Methods of the same type or with the same function should be named the same or similarly.

 // This method is defined in the three classes NSView, NSControl, and NSCell.
 - (NSInteger)tag;
 // This property is defined in both NSDcitionary and NSArray.
 @property (readonly) NSUInteger count ;

[Must] Apple Dad said: If a method represents an action performed by a noun, the method should start with a verb. As follows:

 - (void)invokeWithTarget:(id)target;
 - (void)selectTabViewItem:(NSTabViewItem *)tabViewItem

[Must] Apple also said: If the method represents an action that the object receives, then the method should start with a verb. But don't use "do" or "does" as part of the method name, because these auxiliary verbs can't add much meaning to the method name, but make the method look more bloated. Also, please don't use adverbs or adjectives before verbs.

[Required] If the method returns a property of the receiver, use the property name as the method name. If the method returns one or more values ​​indirectly, we can use the "getxxx" method name. Otherwise, there is no need to add "get" in front of the method name.

[Required] Only when the method indirectly returns an object or value, it is necessary to use "get" in the method name. This format is only applicable when returning multiple data items. As follows:

 // Get multiple values ​​by passing in pointers
 - (void)getLineDash:( float *)pattern count :( int *) count phase:( float *)phase;
 // Methods declared in NSURLCache (NSURLSessionTaskAdditions)
 - (void)getCachedResponseForDataTask:(NSURLSessionDataTask *)dataTask completionHandler:(void (^) (NSCachedURLResponse * __nullable cachedResponse))completionHandler;

[Required] Keywords should be added before all parameters unless you can guarantee that everyone can understand your spirit.

[Suggestion] Apple Dad said: The words before the parameter should describe the meaning of the parameter as much as possible.

[Required] If the method created by the current subclass is more specific and explicit than the method inherited from the parent class, and the method provided by the subclass itself is more targeted, the method provided by the class itself should not be overwritten. Instead, a separate method should be provided, and the necessary key parameters should be added after the new method.

 //Methods provided by UIView
 - (instancetype)initWithFrame:(CGRect)frame
 // A more targeted approach
 - (instancetype)initWithFrame:(CGRect)frame mode:( int )aMode cellClass:(Class)factory Id numberOfRows:( int ) rows numberOfColumns:( int )cols;

[Suggestion] Please do not use "and" to connect the receiver properties. Although and reads smoothly in the following example, it will bring a series of problems as the number of method parameters you create increases.

[Suggestion] If a method describes two independent actions, you can use "and" to connect them.

(1.4) Accessor naming conventions

Accessor Methods refer to set and get methods. These methods have some recommended writing formats:

[Suggestion] If the attribute is a noun, the recommended format is as follows:

 - (type) noun;
 - (void)setNoun:(type)aNoun;
 For example:
 - (NSString *)title;
 - (void)setTitle:(NSString *)aTitle;

[Suggestion] If the attribute represents an adjective, the recommended format is as follows:

 - (BOOL)isAdjective;
 - (void)setAdjective:(BOOL)flag;
 For example:
 - (BOOL)isEditable;
 - (void)setEditable:(BOOL)flag;

[Suggestion] If the attribute is a verb, use the present tense. The recommended format is as follows:

 - (BOOL)verbObject;
 - (void)setVerbObject:(BOOL)flag;
 For example:
 - (BOOL)showsAlpha;
 - (void)setShowsAlpha:(BOOL)flag;

Do not use the past participle of a verb as an adjective.

[Suggestion] You can use modal verbs (can, should, will, etc.) to clarify the meaning of the method, but do not use meaningless modal verbs such as do and does.

[Suggestion] It is only necessary to use "get" in the method name when the method indirectly returns a value or when multiple values ​​need to be returned.

Methods that accept multiple parameters should be able to pass nil, because the caller may not be interested in every parameter.

 - (void)getLineDash:( float *)pattern count :( int *) count phase:( float *)phase;

(1.5) Parameter naming conventions

[Required] Do not use "pointer" or "ptr" to name parameters. Use the parameter type rather than its name to indicate whether it is a pointer.

(1.6) Delegate method naming conventions

Delegate methods are also called delegation methods. If a delegate object implements the delegate method of another object, then this object can call the delegate method of the delegate object when a specified event occurs. The naming of delegate methods has some unique formats:

[Recommendation] Start with the name of the object that triggers the message, omit the class name prefix and lowercase the first letter:

 - (BOOL)tableView:(NSTableView *)tableView shouldSelectRow:( int )row;
 - (BOOL)application:(NSApplication *)sender openFile:(NSString *)filename;

[Suggestion] Unless the delegate method has only one parameter, the delegating object that triggers the delegate method call, the colon is immediately after the class name.

 - (BOOL)applicationOpenUntitledFile:(NSApplication *)sender;

[Suggestion] Triggering the delegate method after sending a notification is an exception: when the delegate method is called to tell the delegate object that a notification has been sent, the parameter of this delegate method should be the notification object, not the object that triggered the delegate method.

 - (void)windowDidChangeScreen:(NSNotification *)notification;

[Suggestion] Use the modal verbs did or will to notify the delegate object that something has happened or is about to happen.

 - (void)browserDidScroll:(NSBrowser *)sender;
 - (NSUndoManager *)windowWillReturnUndoManager:(NSWindow *)window;

[Suggestion] Although we can use did and will in the delegate method to ask the delegate whether it can do something on behalf of another object, using should seems more perfect.

 - (BOOL)windowShouldClose:(id)sender;

(1.7) Private method naming conventions

In most cases, the naming rules for private methods are the same as those for public methods. However, you should usually add a prefix to private methods to distinguish them from public methods. Despite this, this naming method of adding a prefix to private methods may cause some strange problems. The problem is: when you derive a subclass from a class in the Cocoa framework (that is, the Cocoa system library), you don't know whether the private method defined in your subclass overrides the private method of the parent class, that is, it is possible that the private method you implement in your subclass has the same name as a private method in the parent class. At runtime, this is very likely to cause some inexplicable problems, and it is also quite difficult to debug and track the problems.

Private methods in Cocoa frameworks (Cocoa system libraries) usually start with an underscore "_" to mark these methods as private (for example, _fooData). Don't ask me why they do this, it's probably the development habit of Apple engineers. Based on this fact, the following two suggestions are provided:

[MUST] Do not use an underscore " _ " at the beginning of a private method name. Apple has reserved this naming convention for private methods.

[Suggestion] If you are subclassing a very large and complex class in the Cocoa Frameworks (such as NSView or UIView), and you want to be absolutely sure that the private method names in your own subclass do not repeat the private method names in the parent class. You can add a prefix of your own as a prefix of the private method, and this prefix should be as unique as possible. Perhaps this prefix is ​​based on the abbreviation of your company or project, such as "XX_".

Although adding a prefix to private methods may seem to conflict with the previous statement that methods exist in the namespace of their class, the intention here is that adding a prefix to subclass private methods is only to ensure that the subclass method names do not conflict with the parent class method names.

[Required] Do not use "pointer" or "ptr" in the name of a parameter. The parameter type should be used to indicate whether the parameter is a pointer.

[Required] Do not use one or two characters as parameter names.

[MUST] Do not abbreviate every word of a parameter.

[Suggestion] If a method is called to notify the delegate that an event is "about to" happen or "has" happened, use auxiliary verbs such as "will" or "did" in the method name. For example:

 - (void)applicationWillResignActive:(UIApplication *)application;
 - (void)applicationDidEnterBackground:(UIApplication *)application;

[Suggestion] If a method is called to ask the delegate to perform something on behalf of other objects, we should use modal verbs such as "should" in the method. Of course, you can also use words such as "did" or "will" in the method, but the former is more preferred.

 - (BOOL)tableViewSholdScroll:(id)sender;

(1.8) Category naming convention

[Required] Do not declare properties and member variables in category.

[Must] Avoid having methods in a category override system methods. You can use a prefix to distinguish system methods from category methods. However, do not use only an underscore "_" as the prefix.

[Suggestion] If a class is complex, it is recommended to organize the code using category. For details, please refer to UIView.

1.9 Class Naming Standards

[Required] The class name should consist of two parts: prefix + name. That is, the class name should contain a prefix and a noun.

(1.10) Protocol naming convention

[Suggestion] Sometimes a protocol just declares a bunch of related methods and is not associated with a class. This kind of protocol that is not associated with a class uses the ing form to distinguish it from the class. For example, NSLocking instead of NSLock.

[Suggestion] If proctocol not only declares a bunch of related methods, but also associates a class, the name of the protocol of this associated class should depend on the associated class, and then add protocol or delegate to explicitly declare that this is a protocol.

(1.11) Notification naming convention

[Suggestion] Apple said: If a class declares a delegate property, usually the delegate object of this class can receive most notification messages through the implemented delegate methods. Then, the names of these notifications should reflect the corresponding delegate methods. For example, the NSApplicationDidBecomeActiveNotification notification sent by the application object and the corresponding applicationDidBecomeActive: message. In fact, this is also a requirement for naming consistency.

[Required] Notification names are identified using global NSString strings. The naming method is as follows:

 [ Name   of associated class] + [Did | Will] + [UniquePartOfName] + Notification

For example:

 NSApplicationDidBecomeActiveNotification
 NSWindowDidMiniaturizeNotification
 NSTextViewDidChangeSelectionNotification
 NSColorPanelColorDidChangeNotification

[Required] object usually refers to the object that sends the notification. If you want to pass some additional information while sending a notification, use userInfo instead of object.

[Required] If a notification is intended to inform the outside world that an event is "about to" happen or "has" happened, please use auxiliary verbs such as "will" or "did" in the notification name. For example:

 UIKeyboardWillChangeFrameNotification;
 UIKeyboardDidChangeFrameNotification;

(1.12) Constant naming convention

(1.12.1) Enumeration constants

[Required] Use an enumeration type to represent a group of related integer constants.

[Suggestion] The naming convention for enumeration constants and enumeration types defined by typedef should be consistent with the naming convention for functions.

 typedef enum _NSMatrixMode {
    NSRadioModeMatrix = 0,
    NSHighlightModeMatrix = 1,
    NSListModeMatrix = 2,
    NSTrackModeMatrix = 3
 } NSMatrixMode;

Note: The _NSMatrixMode in the above enum typeof is useless.

We can create an anonymous enumeration like bit masks, as follows:

 enum {
    NSBorderlessWindowMask = 0,
    NSTitledWindowMask = 1 << 0,
    NSClosableWindowMask = 1 << 1,
    NSMiniaturizableWindowMask = 1 << 2,
    NSResizableWindowMask = 1 << 3
 };

(1.12.2) Using the const keyword to create constants

[Required] Use the const keyword to create floating-point constants. You can also use const to create integer constants that are not related to other constants. Otherwise, use an enumeration type to create them. That is, if an integer constant is not related to other constants, use const to create it. Otherwise, use an enumeration type to represent a group of related integer constants.

The following example declares the format of a const constant:

 const float NSLightGray;

1.12.3 Other constant types

[Required] Normally, do not use the #define preprocessor command to create constants. As mentioned above, for integer constants, use enumerations; for floating-point constants, use the const modifier.

[Required] Some symbols need to be identified with uppercase letters. The preprocessor needs to calculate based on this symbol to decide whether to process a certain piece of code. For example:

 #ifdef DEBUG

Note: The compiler-defined macros have two underscores on the left and right.

 __MACH__

[Required] Notification names and dictionary keys should be defined using string constants. The compiler can check string constants to avoid spelling errors. The Cocoa system library provides many examples of string constants, such as:

 APPKIT_EXTERN NSString *NSPrintCopies;

String constants should be exposed to the outside in the .h header file, and the actual assignment of string constants is in the .m file. As follows:

 .h files
 extern NSString *const WSNetworkReachablityStatusDidChangedNotification;
 .m file
 NSString * const WSNetworkReachablityStatusDidChangedNotification = @ "WSNetworkReachablityStatusDidChangedNotification" ;

(1.13) Exception naming convention

The section above already introduced the naming conventions for notifications. The naming conventions for exceptions and notifications follow similar rules, but they are also different.

[Required] The naming convention is the same as that of Notification (see the Notification Naming Convention section). Exceptions are also identified by global NSString strings. The naming method is as follows:

[Prefix] + [UniquePartOfName] + Exception

It is equivalent to the exception prefix, the part of the name that can identify the uniqueness of the exception, and Exception. As follows:

 NSColorListIOException
 NSColorListNotEditableException
 NSDraggingException
 NSFontUnavailableException
 NSIllegalSelectorException

(II) Coding Standards

(2.1) Initialize specification

(void) The initialize class method is called before other methods. The initialize method provides us with a place to execute code once or lazily. initialize is usually used to set the version number of the class (see Versioning and Compatibility). (https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/FrameworkImpl.html#//apple_ref/doc/uid/20001286-1001777)

The call of initialize method follows the inheritance rules (the so-called inheritance rules, in simple terms, mean that the subclass method can call the parent class method with the same name, even if [super xxx] is not called). If we do not implement the initialize method, when the runtime calls this class for the first time, the system will follow the inheritance chain (class inheritance system) and send an initialize message to each superclass upstream of the inheritance chain, until a superclass implements the initialize method, and then stop calling upward. Therefore, at runtime, the initialize method of a class may be called multiple times (for example, if a subclass does not implement the initialize method).

For example, there are three classes: SuperClass, SubClass and FinalClass. Their inheritance relationship is FinalClass->SubClass->SuperClass. Currently, only the initialize method of SuperClass is implemented.

 //SuperClass
 @implementation SuperClass
 + (void)initialize {
    NSLog(@ "superClass initalize" );
 }
 @ end  
 // Initialize FinalClass
 - (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
    FinalClass *finalC = [FinalClass new];
 }
 // Console output results
 2018-01-27 22:11:03.130365+0800 Demo[67162:11721965] superClass initalize
 2018-01-27 22:11:03.130722+0800 Demo[67162:11721965] superClass initalize
 2018-01-27 22:11:03.130815+0800 Demo[67162:11721965] superClass initalize

explain:

Because FinalClass inherits from SubClass, and SubClass inherits from SuperClass. Because only SuperClass in the inheritance system implements the initialize method, when the subclass FinalClass is initialized, FinalClass will call the initialize method in its parent class (SubClass). And because its (FinalClass) parent class (SubClass) does not implement the initialize method either, it will continue to search upstream along the inheritance system and finally find the parent class of SubClass (SuperClass). Because SuperClass implements this initialize method, the call ends. As for why the initialize method of SuperClass is called three times in a row. Because the initialization of the subclass FinalClass triggers the initialization of the superclasses SubClass and SuperClass. So when initializing FinalClass, these three classes actually get the opportunity to be initialized, and naturally the initialize method of SuperClass will be called three times in a row.

Still the above three classes, if we implement the initialize method for SubClass, the console will output the following results (as for why, it has been introduced before, you can analyze it yourself):

 2018-01-27 22:34:54.697952+0800 Load [67652:11780578] superClass initalize
 2018-01-27 22:34:54.698118+0800 Load [67652:11780578] subClass initialize
 2018-01-27 22:34:54.698472+0800 Load [67652:11780578] subClass initialize

Based on the facts stated above, we come to a conclusion:

[Required] If we want the initialize method to be called only once, we need to use GCD's dispatch_once() as follows:

 + (void)initialize {
 static dispatch_once_t onceToken = 0;
    dispatch_once(&onceToken, ^{
        // the initializing code
 }
 }

[Suggestion] If we want to execute some initialization code in the initialize method of a specified class in the inheritance system, we can use type checking instead of dispatch_once(). As follows:

 if (self == [NSFoo class]) {
 // the initializing code
 }

Having said so much, in short, since any subclass will call the parent class's initialize method, it may cause the initialize method of a parent class to be called multiple times. In order to avoid this situation, we can use type equality or dispatch_once() to ensure that the code in initialize will not be called innocently.

Initialize is a method that is automatically called by the system. We should not display or manually call the initialize method. If we want to trigger the initialization behavior of a class, we should call some harmless methods of this class. For example:

 [NSImage self];

(2.2) Init method specification

Objective-C has the concepts of designated Initializers and secondary Initializers. Designated Initializers are called designated initialization methods. "Effective Objective-C 2.0 52 Effective Ways to Write High-Quality iOS and OS X Code" translates designated Initializers as "all-purpose initialization methods." Designated Initializers methods refer to initialization methods in a class that provide objects with necessary information so that they can complete their work. A class can have one or more designated Initializers. But make sure that all other secondary initializers call designated Initializers. That is, only designated Initializers will store object information. The advantage of this is that when some underlying data storage mechanisms of this class change (perhaps changes to some properties), you only need to modify the code inside this designated Initializer. There is no need to change the code of other secondary Initializers initialization methods.

【Required】All secondary initialization methods should call the designated initialization method.

[Required] All designated initialization methods of subclasses must call designated initialization methods of superclasses, so that this calling relationship forms a chain along the class inheritance system.

[Required] If the designated initialization method of a subclass is different from that of the superclass, the subclass should override the designated initialization method of the superclass. (Because developers are likely to directly call a designated method of the superclass to initialize a subclass object, which is reasonable, but using the superclass method to initialize a subclass may cause the subclass to lack some necessary information during initialization).

[Required] If a superclass initialization method is not applicable to a subclass, the subclass should override the superclass method and throw an exception in it.

[Must] The designated initialization method of the subclass is prohibited from calling the secondary initialization method of the parent class. Otherwise, it is easy to fall into a method call infinite loop. As follows:

 // Superclass
 @interface ParentObject : NSObject
 @ end  
 @implementation ParentObject
 //designated initializer
    - (instancetype)initWithURL:(NSString*)url title:(NSString*)title {
        if (self = [super init]) {
            _url = [url copy];
            _title = [title copy];
 }
 return self;
 }
 //secondary initializer
    - (instancetype)initWithURL:(NSString*)url {
 return [self initWithURL:url title:nil];
 }
 @ end  
 // Subclass
 @interface ChildObject : ParentObject
 @ end  
    @implementation ChildObject
 //designated initializer
    - (instancetype)initWithURL:(NSString*)url title:(NSString*)title {
 //Calling secondary initializer in designated intializer is wrong
        if (self = [super initWithURL:url]) {
 }
 return self;
 }
 @ end  
 @implementation ViewController
 - (void)viewDidLoad {
 [super viewDidLoad];
 // This will cause an infinite loop
        ChildObject* child = [[ChildObject alloc] initWithURL:@ "url" title:@ "title" ];
 }
 @ end  

[Required] Also, it is forbidden to use self.xxx to access attributes in the init method. If inheritance exists, it is likely to cause a crash.

(2.3) Init error

A good initialization method should have the following aspects, so that errors can be discovered and handled during the initialization phase. In other words, the initialization method should have some necessary fault-tolerant functions.

[Required] Call the designated initialization method of the parent class to initialize objects of this class.

[Required] Check whether the object returned by the designated initialization method of the parent class is nil.

[Suggestion] If an error occurs when initializing the current object, corresponding processing should be given: release the object and return nil.

The following examples list possible errors that may occur during the class initialization phase:

 - (id)init {
    self = [super init]; // Call a designated initializer here.
 if (self != nil) {
        // Initialize object ...
 if (someError) {
 [self release];
 self = nil;
 }
 }
 return self;
 }

(2.4) dealloc specification

[Required] Don't forget to remove notifications and KVO in the dealloc method.

[Suggestion] The dealloc method should be placed at the top of the implementation file, just after the @synthesize and @dynamic statements. In any class, init should be placed directly below the dealloc method.

[Required] In the dealloc method, it is forbidden to pass self as a parameter. If self is retained and released in the next runloop cycle, it will cause multiple release crashes. As follows:

 -(void)dealloc{
 [self unsafeMethod:self];
 // Because the object pointed to by the self pointer is currently being destroyed, it is inevitable to destroy the object pointed to by self. If self is put into the autorelease poll in unsafeMethod:, then self will be retained and scheduled to be destroyed in the next runloop cycle. However, after the dealloc is completed, the memory space of the object pointed to by self is directly reclaimed, but the self pointer has not been destroyed (that is, it has not been set to nil), causing self to become a veritable wild pointer.
 // In the next runloop cycle, because the object pointed to by self has been destroyed, a crash problem will be caused due to illegal access.
 }

[Required] As with the init method, it is forbidden to use self.xxx to access properties in the dealloc method. If inheritance exists, it is likely to cause a crash.

(2.5) Block Specification

[Required] When calling a block, you need to check if the block is empty.

【Must】Be aware of potential reference cycles in blocks.

(2.6) Notification Specification

The naming conventions for notifications have been introduced in the previous chapter on naming conventions. Here we explain the usage conventions for notifications.

As a landing product of the observer model, notifications can realize one-to-many communication during development. All communications and values ​​that can be implemented using delegate and block can be implemented using notifications. Because notifications are so flexible, we should also figure out the scenarios that notifications are suitable for use and avoid confusing notifications with delegate and block.

Notifications are a double-edged sword that makes you happy and worry. During development, when you are desperate and are about to collapse, you can consider using notifications; and when you use notifications frequently, it will also cause you to be desperate. Therefore, in each application, we should always pay attention to and control the number of notifications to avoid the phenomenon of notifications flying all over the sky.

There was once a project in front of me, but I couldn't cherish it because there were too many notifications, and there were notifications almost everywhere there were code. If there was also a project in front of me now, I knew it was time to optimize it.

【Must】Based on the above statement, when we use notifications, we must think about whether there is a better way to replace this notification. It is forbidden to think of notifications when encountering problems, and use notifications as alternatives rather than preferences.

[Must] When post notification, object usually refers to the object that issues notification. If you want to pass some extra information while sending notification, please use userInfo instead of object.

【Must】NSNotificationCenter has a multi-threaded bug in iOS8 and older systems. The candidate may cause crash due to self-destruction in half. The solution is to use weak_strong_dance in the selector. The following:

 - (void)onMultiThreadNotificationTrigged:(NSNotification *)notify {
    __weak typeof(self) wself = self; __strong typeof(self) sself = wself;
 if (!self) { return ; }
 [self doSomething];
 }

[Must] In a multi-threaded application, the Notification is forwarded in which thread, not necessarily in the thread where the observer is registered. If the post message is not in the main thread, but the callback that accepts the message performs UI operations, it needs to be executed in the main thread.

Note: Each process will create a NotificationCenter, which is obtained through the NSNotificationCenter defaultCenter. Of course, you can also create a center by yourself.

The NoticiationCenter sends requests in a synchronous manner (non-asynchronous, current thread, will wait, block) way. That is, when posting notifications, the center will wait for all observers to receive and process notifications before returning to the poster. If you need to send notifications asynchronously, please use notificationQueue. In a multi-threaded application, notifications will be sent to all threads.

(2.7) UI specifications

【Must】If you want to get window, do not use view.window to get it. Please use [[UIApplication sharedApplication] keyWindow].

[Must] In the Class that uses UIScrollView, UITableView, and UICollectionView, the corresponding delegate and dataSouce need to be manually set to nil in the dealloc method.

[Must] When UITableView uses self-sizing to implement unequal cell, please set data for the cell in the - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath;. Do not set data for the cell in the - (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath; method.

[Suggestion] When accessing a CGRect's x, y, width, height, you should use the CGGeometry function instead of directly accessing the structure members. Apple's CGGeometry reference says:

• All functions described in this reference that take CGRect data structures as inputs implicitly standardize those rectangles before calculating their results. For this reason, your applications should avoid directly reading and writing the data stored in the CGRect data structure. Instead, use the functions described here to manipulate rectangles and to retrieve their characteristics.

Therefore, the recommended writing method is as follows:

 CGRect frame = self. view .frame; 
 
 CGFloat x = CGRectGetMinX(frame);
 CGFloat y = CGRectGetMinY(frame);
 CGFloat width = CGRectGetWidth(frame);
 CGFloat height = CGRectGetHeight(frame);

Oppose this writing:

 CGRect frame = self. view .frame; 
 
 CGFloat x = frame.origin.x;
 CGFloat y = frame.origin.y;
 CGFloat width = frame. size .width;
 CGFloat height = frame. size .height;

(2.8) IO specifications

【Suggestions】Try to use NSUserDefaults as little as possible.

Description: [[NSUserDefaults standardUserDefaults] synchronize] will block the current thread and know that all the content is written to disk. If there is too much content, repeated calls will seriously affect performance.

【Suggestions】It is recommended to cache some frequently used files. Avoid duplicate IO operations. It is recommended to perform persistence operations only when appropriate.

2.9 Collection Specification

【Must】Don't initialize the collection object with an object that may be nil, otherwise it may cause crash.

 // May crash
 NSObject *obj = somOjbcetMaybeNil;
 NSMutableArray *arrM = [NSMutableArray arrayWithObject:obj];
 // Crash message:
 *** Terminating app due to uncaught exception 'NSInvalidArgumentException' , reason: '*** -[__NSPlaceholderArray initWithObjects: count :]: attempt to   insert nil object from objects[0]'

 // Improvement method:
 NSObject *obj = somOjbcetMaybeNil;
 NSMutableArray *arrM = nil;
 if (obj && [obj isKindOfClass:[NSObject class]]) {
    arrM = [NSMutableArray arrayWithObject:obj];
 } else {
 arrM = nil;
 }

[Must] Similarly, the objects inserted into the collection object must also be judged to be empty.

[Must be] Pay attention to the problem of accessing mutable collection objects in a multi-threaded environment, and lock protection should be added if necessary. The immutable collection (such as NSArray) class is thread-safe by default, while the mutable collection class (such as NSMutableArray) is not thread-safe.

【Must】It is prohibited to directly access elements in mutable collection objects in a multi-threaded environment. It should be copied first, and then access elements in the immutable collection objects.

 // Correct writing
 - (void)checkAllValidItems{
 NSArray *array = [array copy];
 [array enumerateObjectsUsingBlock:^(id _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
 //do something using obj
 }]; } 
 
 // Error writing
 - (void)checkAllValidItems{
 [self.allItems enumerateObjectsUsingBlock:^(id _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
 //do something using obj
 // If other threads change the variable set of allItems during the enumerate process, it is possible to cause crash
 }]; }

[Must] Pay attention to the scope of the keyword return when using enumerateObjectsUsingBlock to traverse objects in the collection object. The return in the block represents the return of the current block, rather than the entire current function body. The following uses NSArray as an example, and the same applies to other collection types. As follows:

 - (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
    NSArray *array = [NSArray arrayWithObject:@ "1" ];
    [array enumerateObjectsUsingBlock:^(id  _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
        // excute some code...
 return ;
 }];
 // Will still execute it here
 NSLog(@ "fall through" );
 } 
 
 // Execution results:
 // fall through

Of course, if two enumerateObjectsUsingBlocks are nested, if they are returned only in the innermost block, the code of the outer block will still be executed. As follows:

 - (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
    NSArray *arr1 = [NSArray arrayWithObject:@ "1" ];
    NSArray *arr2 = [NSArray arrayWithObject:@ "2" ];
    [arr2 enumerateObjectsUsingBlock:^(id  _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
        [arr1 enumerateObjectsUsingBlock:^(id  _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
 // do something
 return ;
 }];
        NSLog(@ "fall through" );
 }];
 NSLog(@ "fall through" );
 } 
 
 // Execution results:
 // fall through
 // fall through

Note: In fact, block is equivalent to an anonymous function. Return is used in block, which only allows the current anonymous function to return.

[Must] The return of mutable objects is prohibited, and the mutable objects are prohibited as incoming parameters.

【Suggestions】If you use NSMutableDictionary as cache, it is recommended to use NSCache instead.

[Suggestion] Collection classes use generics to specify the type of the object.

 @property(nonatomic,copy) NSArray<NSString *> *array;
 @property(nonatomic,strong) NSMutableDictionary<NSString *,NSString *> *dictionary;

(2.10) Branch statement specification

[Suggestion] If condition judgment statement must be followed by curly brackets {}. Otherwise, with the development of the business and the iteration of the code, it is very likely to cause logical problems.

 // suggestion
 if (!error) {
 return success;
 }
 // Not recommended
 if (!error)
 return success;
 if (!error) return success;

[Must] More than 3 logical expressions must be divided into multiple meaningful bool variables with parameters.

[Suggestions] Follow the gold path rule and do not write real logic into brackets.

 // Not recommended
 - (void)someFuncWith:(NSString *)parameter {
 if (parameter) {
 // do something
 [self doSomething];
 }
 }
 // suggestion
 - (void)someFuncWith:(NSString *)parameter {
 if (!parameter) {
 return ;
 }
 // do something
 [self doSomething];
 }

【Suggestions】For the authenticity of the conditional statement, since nil resolves to NO, there is no need to compare it in the condition. Never compare it directly with YES and NO, because YES is defined as 1, and BOOL can have up to 8 bits.

 // suggestion
 if (isAwesome)
 if (![someObject boolValue])
 // This is prohibited
 if ([someObject boolValue] == NO ) { }
 if (isAwesome == YES) { }

[Must] Do not throw away default: when using the switch...case... statement. Unless the switch enumeration is used.

[Must] Each case of the switch...case... statement must be added to the break keyword to avoid fall-through.

(2.11) Object judgment and other specifications

The isEqual: method allows us to pass in any type of object as a parameter. If the parameter type and receiver (method caller) type are inconsistent, it will return NO. The two methods are EqualToString: and isEqualToArray: these two methods assume that the parameter type and receiver type are the same, that is, these two methods will not perform type checks on the parameters. Therefore, these two methods perform better but not safe. If we are getting data from an external data source (such as info.plist or preferences), it is recommended to use isEqual: because it is safer. If we know the exact type of the parameter, we can use a method similar to isEqualToString: because it has better performance.

(2.12) Lazy loading specification

Lazy loading suitable scenarios:

1. The creation of one object depends on other objects.
2. An object may or may not be used throughout the entire app process.
3. The creation of an object requires a lot of calculations or consumes performance. In addition to the above three items, please do not use lazy loading.

[Suggestion] Lazy loading is essentially delaying the initialization of an object, so lazily loading is just initializing an object and then assigning values ​​to the properties of this object. Lazy loading should not have other unnecessary logical codes. If so, please put those logical codes in the appropriate place.

【Must】Don't abuse lazy loading, only use lazy loading for objects that really need lazy loading.

【Must】If an object is set to nil after lazy loading, it is difficult for us to ensure that this lazy loading is not triggered again.

(2.13) Multithreading specification

[Must] Use of GCD's dispatch_get_current_queue() function is prohibited from obtaining the current thread information.

[Must] Reading of the clipboard must be processed in asynchronous threads. The latest clipboard sharing function in Mac and iOS may cause a large amount of content to be read, resulting in the reading thread being blocked for a long time.

[Suggestion] Use dispatch_sync only when sequential execution must be guaranteed. Otherwise, deadlocks are prone to occur and should be avoided. Use dispatch_async.

 - (void)viewDidLoad {
 [super viewDidLoad];
 // Error. A deadlock occurred, an error reported: EXC_BAD_INSTRUCTION. Reason: Add a block to the main queue synchronously in the main queue.
   dispatch_queue_t mainQueue = dispatch_get_main_queue();
   dispatch_block_t block = ^() {
       NSLog(@ "%@" , [NSThread currentThread]);
 };
   dispatch_sync(mainQueue, block);
 }

 - (void)viewDidLoad {
 [super viewDidLoad];
 // Correct. Asynchronous execution. Although the task is still added to the main queue and executed by the main thread, because it is asynchronous, the tasks behind the main queue do not depend on the previous tasks.
   dispatch_queue_t mainQueue = dispatch_get_main_queue();
   dispatch_block_t block = ^() {
       NSLog(@ "%@" , [NSThread currentThread]);
 };
   dispatch_async(mainQueue, block);
 }
 // Print result:
 // <NSThread: 0x600000073300>{number = 1, name = main}

【Must】Operation of UI elements in non-main threads is prohibited.

【Must】Synchronous network resource reading is prohibited in the main thread, and use NSURLSession for asynchronous acquisition. Of course, you can obtain network resources synchronously in the child thread, but the above suggestion is still: avoid using dispatch_sync and try to use dispatch_async. Because deadlocks do not necessarily only occur in the main thread.

[Must] If IO operations for large files or multiple files are required, the main thread is prohibited from using it and asynchronous processing must be performed.

[Must] Reading of the clipboard must be processed in asynchronous threads. The latest clipboard sharing function in Mac and iOS may cause a large amount of content to be read, resulting in the reading thread being blocked for a long time.

 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
   UIPasteboard *pasteboard = [UIPasteboard generalPasteboard];
 if (pasteboard.string.length > 0) {//This method will block the thread
      NSString *text = [pasteboard.string copy];
      [pasteboard setValue:@ "" forPasteboardType:UIPasteboardNameGeneral];
      if (text == nil || [text isEqualToString:@ "" ]) {
 return ;
 }
      dispatch_async(dispatch_get_main_queue(), ^{
          [self processShareCode:text];
 });
 }
 });

2.14 Memory Management Specifications

[Suggestion] When returning the function body in advance, be careful whether any objects have not been released (commonly in CF objects) to avoid memory leakage.

[Suggestions] Please use singletons carefully to avoid unnecessary resident memory.

Note: We should not only know the characteristics and advantages of singletons, but also understand the scenarios suitable for singletons. UIApplication, access database, request network, access userInfo and other globally only have one object or objects that require multi-thread access, you can use singletons. Don't use singletons just for the convenience of access.

[Suggestion] Try to ensure a single responsibility in the singleton initialization method, especially not to call other singletons. In extreme cases, two singleton objects are called in their respective singleton initialization methods, which will cause deadlocks.

[Must] In the dealloc method, it is prohibited to pass self as a parameter. If self is retained and released in the next runloop cycle, it will cause crash releases multiple times. This is explained in the dealloc section.

[Suggestions] Unless you clear what you are doing, it is not recommended to add objects of the UIView class to NSArray, NSDictionary, and NSSet. If necessary, you can add them to NSMapTable and NSHashTable. Because NSArray, NSDictionary, and NSSet will refer to the added objects (even if you weaken the added object). NSMapTable and NSHashTable will refer to the added objects.

Note: Simply put, NSHashTable is equivalent to weak NSMutableArray; NSMapTable is equivalent to weak NSMutableDictionary.

 // Error example:
 @implementation WSObject
 - (void)dealloc {
 NSLog(@ "dealloc" );
 }
 @ end  
 - (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
    WSObject *object = [WSObject new];
 // Even if the object is weakened, the array will strongly refer to this object object. The dealloc method will not be executed.
    __weak typeof(object) weakObject = object;
    [self.arrM addObject:weakObject];
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        NSLog(@ "count = %ld" ,self.arrM. count );
 });
 }
 // Print result:
 // count = 1

 // Correct example:
 - (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
    WSObject *object = [WSObject new];
    NSHashTable *hashTable = [NSHashTable weakObjectsHashTable];
    [hashTable addObject:object];
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        NSLog(@ "count = %ld" ,hashTable. count );
 });
 }
 // Print result:
 // dealloc
 // count = 1

You may have some doubts about the above example. The object has been released, but the console still outputs hashTable.count == 1. But believe me, the object that exists in the hashTable has become nil at this time. If you don't believe it, continue to look at the following example:

 - (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event {
    WSObject *object = [WSObject new];
    NSHashTable *hashTable = [NSHashTable weakObjectsHashTable];
    [hashTable addObject:object];
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        NSLog(@ "count = %ld" ,hashTable. count );
        if (hashTable && hashTable. count ) {
            WSObject *object = [hashTable anyObject];
            NSLog(@ "object = %@" ,[object self]);
 }
 });
 }
 // Print result:
 2017-07-04 22:19:10.952139+0800 tst[46834:4305636] dealloc
 2017-07-04 22:19:13.149903+0800 tst[46834:4305636] count = 1
 2017-07-04 22:20:55.234522+0800 tst[46834:4305636] object = ( null )

(2.15) Delayed Call Specification

【Must】 performSelector:withObject:afterDelay: It must be called in a thread with Runloop, otherwise the call will not take effect.

• Note: The asynchronous thread does not have runloop by default, unless it is created manually; the main thread will automatically create runloop by the system. Therefore, when calling asynchronous thread, please make sure that the thread has runloop first.

Be careful when combining performSelector:withObject:afterDelay: and cancelPreviousPerformRequestsWithTarget:

• AfterDelay will increase the reference count, and cancel will reduce the reference count by one

If the receiver reference counter is 1, calling cancel will immediately recycle the receiver. The receiver method will be crashed after calling again. So we need to use weakSelf and judge empty. As follows:

 __weak typeof(self) weakSelf = self;
 [NSObject cancelPreviousPerformRequestsWithTarget:self];
 if (!weakSelf) {
    // NSLog(@ "self dealloc" );
 return ;
 }
 [self doOther];

(2.16) Comment specifications

[Must] If methods, functions, classes, attributes, etc. need to be provided to the outside world or others for use, comments and explanations must be added.

【Must】If your code is provided to others in the form of an SDK, then the annotation of the interface is necessary. All methods, properties, and parameters exposed to the outside world must be commented and explained.

[Suggestions] Notes should explain their functions and precautions (if any).

[Suggestion] Because the method or attribute itself is self-descriptive, the comments should be concise and explain what and why.

(2.17) Design Specifications

[Suggestion] Try to minimize inheritance, and the inheritance relationship of the class should not exceed 3 layers. You can consider using category and protocol instead of inheritance.

[Suggestion] Extract some stable and common variables or methods into the parent class. Subclasses try to maintain only features and functions that are not available to the parent class.

[Suggestions] Try not to declare member variables in the .h file.

[Suggestions] Try to declare the properties in the .h file as read-only.

[Suggestions] Only some necessary classes, public methods, and read-only attributes are exposed in the .h file; private classes, private methods, private attributes, and member variables are written as much as possible in the .m file.

(2.18) Code Organization Specification

参考raywenderlich/objective-c-style-guide(https://github.com/raywenderlich/objective-c-style-guide)

 #pragma mark - Lifecycle
 - (instancetype)init {}
 - (void)dealloc {}
 - (void)viewDidLoad {}
 - (void)viewWillAppear:(BOOL)animated {}
 - (void)didReceiveMemoryWarning {}
 #pragma mark - Custom Accessors
 - (void)setCustomProperty:(id)value {}
 - (id)customProperty {}
 #pragma mark - IBActions
 - (IBAction)submitData:(id)sender {}
 #pragma mark - Public  
 - (void)publicMethod {}
 #pragma mark - Private
 - (void)privateMethod {}
 #pragma mark - UITextFieldDelegate
 #pragma mark - UITableViewDataSource
 #pragma mark - UITableViewDelegate
 #pragma mark - NSCoping
 - (id)copyWithZone:(NSZone *)zone {}
 #pragma mark - NSObject
 - (NSString *)description {}

[Suggestions] The above is just an idea to organize the code. If there are other better ways to organize it, it is not impossible.

(2.19) Engineering Structural Specifications

[Must] To avoid file clutter, physical files should be kept synchronized with Xcode project files. Any groups created by Xcode must have corresponding mappings on the file system. For clearer purposes, codes should not only be grouped by type, but also by business functions.

[Suggestions] Reasonably organize the folders within the project. The project generally includes but is not limited to the following folders category (category), util/helper (tool class), resource (resource), const (const), and third (third party).

【Suggestions】Always open the "Treat Warnings as Errors" in target Build Settings as much as possible and some additional warnings. If you need to ignore the specified warning, use the compilation feature of Clang.