IOS development specifications and ios development

IOS development specifications and ios development

Introduction

Before reading the following, we can check whether the code we write is standardized and whether the code style is too different. Is it difficult to read it? Can I read peer code? Is there any reading barrier?

If the code is obscure and the cost increases, your team needs to be self-examined.

The following summarizes some code specifications in OC programming (officially recommended by Apple ). Take OC as an example, but it is not limited to OC. It can also be used as a standard convention for development in other programming languages (you only need to keep the OC-specific things in accordance with the conventions of your language)

References: descriptions of the recommended code specifications in Apple code specifications

Name

Naming rules are very important for code maintenance ,. The Objective-C method name is often long, but it also benefits to make many annotations meaningless.

This article recommends the hump method, which is also the standard of the Objective-C community.

The hump method is divided into the small and large hump methods. Small hump method: except the first word, the first letter of other words is capitalized. Compared with the small hump method, the big hump method also capitalized the first word.

1. Basic Principles

1.1 clear

Clarity and conciseness are the best, but conciseness is not as important as clarity. In general, do not use abbreviations of words. In addition to frequently used abbreviations, try to use the full name of words. Do not have any ambiguity in the API name. When you look at your API, you will know how it is done and do not doubt it.

1.2 consistency

This is usually the name of the code used to do something, such as tag and setStringValue. When you are not sure how to get the name, you can refer to some common names: Method Arguments

2. Class Name

The class name (excluding the class name and protocol name) should start with a big camper name. The class name should contain one or more nouns to illustrate what the class (or Class Object) is.

In application-level code, do not use a class name with a prefix. Each class has the same prefix, which cannot improve readability. However, if you are writing shared code between multiple applications, the prefix is acceptable and recommended (type: JKPhotoBrowser ).

Example 1:

@ Interface ImageBrowseView: UIView

@ End

Example 2: (JK with a prefix)

@ Interface JKPhotoBrowser: UIView

@ End

3. category naming

Class Name + ID + extension (UIImageView + HP + Web)

For example, if we want to create a category based on UIImageView for network request images, we should set the category

Put it in the file named UIImageView + HPWeb. h. UIImageView is the name of the class to be extended, and HP is the exclusive label

Knowledge, Web is an extended function.

Class methods should all use a prefix (type such as hp_myCategoryMethodOnAString) to prevent Objective-

The C code conflicts in a single-Name Space. If the code is not shared or in a different address space (address-

Space), there is no need to stick to the method naming rules.

Class HPWeb header file, UIImageView + HPWeb. h:

@ Interface UIImageView (HPWeb)

-(Void) hp_setImageWithURLString :( NSString *) urlStr;

@ End

4. Method naming

The method is named by the small hump method. A standard method should read like a complete sentence, and the function will be known after reading it.

. The execution method should start with a verb and start with a lowercase letter. The return method should start with the returned content.

But do not add get before.

Example:

-(Void) replaceObjectAtIndex :( NSUInteger) index withObject :( id) anObject;

(Instancetype) arrayWithArray :( NSArray *) array;

If there is a parameter, the function name should be used as the prompt information for the first parameter. If there are multiple parameters, there should also be

Prompt message (and is not required in general)

Some classic operations should use agreed verbs, such as initWith, insert, remove, replace, and add.

5. variable naming

Variable names use the small hump method to make them descriptive. Don't try a few times

Letter, so that your code can be quickly understood more important.

5.1 class member variables:

Member variables are named by the small hump method and prefixed with underscores. Objective-C 2.0, @ property and @ synthesize provide

Solutions to compliance with naming rules

Example:

@ Interface ViewController ()

@ Property (nonatomic, strong) NSMutableArray * dataArray;

@ Property (nonatomic, strong) UITableView * tableView;

@ End

@ Implementation ViewController

@ End

5.2 General variable naming

Example:

NSMutableArray * ticketsArray = [NSMutableArrayarrayWithCapacity: 0];

NSInteger numCompletedConnections = 3;

5.3 constant name

Constants (pre-defined, enumeration, local constants, etc.) use the hump method starting with lowercase k, such as kInvalidHandle,

KWritePerm

Example:

# Define kRunAnnotationStartPointTitle @ "start point"

Typedef NS_ENUM (NSInteger, RunGoalTypeE ){

KRunGoalTypeNone = 0, // No target

KRunGoalTypeTime = 1, // time-oriented

KRunGoalTypeDistance = 2, // The distance is the target

KRunGoalTypeCalori = 3, // aims to consume calories

};

NSString * const kGroupInfoName = @ "name ";

6. Image resource file name

Let's take a look at the naming method of Sina Weibo app Image resources. The following sections are available:

This image resource naming method, in the form of functions, is a good habit and is conducive to viewing resource files.

Principles:

1) Use words in full spelling, or are generally recognized as non-representative abbreviations (such as nav, bg, and btn)

2) The "module + function" naming method is adopted. modules are divided into public modules and private modules. The public module mainly includes a unified back-to-back

Scenes, navigation bars, labels, public button backgrounds, public default charts, etc. Private modules are mainly based on app services.

Function modules, such as user center and message center

Note: It is recommended that the background image be prefixed with bg and the button background be prefixed with btn (not mandatory, project reality

The person in charge can be determined based on the characteristics of the team)

Public module naming example:

Navigation bar back pictures: bg_nav_bar@2x.png

Return buttons in the navigation bar: bg_nav_back_normal@2x.png,bg_nav_back_selected@2x.png

Label item Background: bg_tabbar_record_normal@2x.png,bg_tabbar_record_selected@2x.png

Private module naming example:

Taking the user center image resources of the Joggers APP as an example,

Uc -- user center

User center Avatar default diagram: bg_uc_avatar@2x.png

User center top Default background map: bg_uc_top_defaut@2x.png

User center bottom Background: bg_uc_bottom@2x.png

This part of the work is complicated, and programmers will think it is a job with low technical content, but the image name

The rigor also reflects our pursuit of details. Details determine success or failure.

File Organization Structure

1. Class file organization

The iOS project file structure is divided into physical and logical structures. It is recommended that the logical structure be consistent with the physical structure to facilitate and effectively manage files. The following two principles must be followed:

Based on the MVC design pattern principle, at least the controller and data processing must be ensured, and network requests must be relatively independent.

Based on the functional module principle, the functional module consists of two parts: Data/network processing and UI front-end interface. Data/network processing should be implemented under the framework of data/network processing, the UI front-end interface, such as the user center, message center, their proprietary controller, view, and so on, should belong to folders. Some public views can also be opened up to manage public folders.

In actual use, the actual project owner can flexibly use the features of the project, but the basic principles must be maintained to maintain a good class file organization structure, which is beneficial to the team.

2. Image resource file organization

Image resource files. It is strongly recommended to use Images. xcassets for management and use as few folders as possible.

Use Images. xcassets has many advantages. For details, refer to relevant documents. Here we only talk about one point in Engineering Management, in Images. adding image resources to xcassets does not change the project file. Adding an image file to a folder changes the project file every time. Therefore, Images is used. xcassets can be used to manage image resources to reduce the number of project conflicts.

Is the file organization structure of Joggers:

Maintains the consistency of the physical/logical structure in strict accordance with the above discussions on the structure of organizational documents, facilitating the inspection and replacement between teams

And shared resources.

Class Code organization principles

One principle: dealloc (void) is best placed at the top of the class. You can see this method at first glance to see if some operations are removed, reasonable memory release, etc. The controller and view life cycle functions are placed at the top, and the methods implemented by the user are listed below. The methods with the same/similar functions are marked by # pragma mark, for viewing.

Example:

The first part focuses on the easy-to-grasp and easy-to-promote content, and briefly discusses the content that is actually helpful for team development, mainly focusing on naming and document organization principles, the corresponding example is provided. The specifications are implemented by project owners. It seems that I have forgotten something. Yes, comments. I didn't elaborate on the comments above. Good code habits are good comments. Therefore, I will not discuss comments here, note requirements should be agreed by the project owner.

@ Fu's team requirements

IOS code specification


1. Delete unnecessary empty rows.
* One Line is blank between all methods and methods.
* One Line is blank between all code blocks.
2. Delete unnecessary comments
* Delete the commented-out code
* Delete meaningless comments
3. Delete redundant Methods
* If the method is not used, delete it.
* If the method does not execute any business logic, delete it or give some comments.
4. delete unused resource files
5. add necessary comments
* All the properties in the. h file need to be annotated.
* Comments are required for all custom methods.
* Comments must be given for large code blocks.
* All Arabic numbers in the Code must be annotated.
* If an encryption/Decryption logic operation occurs in the program, you need to describe the process with a comment (whether it is a system or custom operation)
6. Unified overall code style
* "{" After the Code does not need to occupy a single row
* Logical operators and code are empty
* "# Pragma mark-" and the following code should not be empty lines
* Follow General code specifications


General rules for iOS


1. All the following rules are not bound to third-party class libraries.
* All classes, methods, attributes, and other names are named by name and use the hump naming rules.
* Project resources are grouped by resource type or business logic to make the entire project structure clear and clear.
* The entire project maintains a code writing style (this style is determined by the Wuxi team based on their coding habits), making your code more elegant!
2. Naming rules
* Names of all classes start with a project. For example, "XP", "ZJG", and "SZ"
* For different view controllers, add the suffix at the end, for example:
* Add "ViewController" to the suffix of UIViewController"
* Add "View" to the suffix of UIView"
* Add "Button" to the UIButton suffix"
* Add "Label" to the UILabel suffix"
3. It is best to control code on a single page within 800 lines, and each method should not exceed 100 lines. We recommend that you refactor the code too much.
4. The same logical method definition should not appear in multiple places. Try to extract public classes and Methods
5. delete unused code. Do not comment out unused code in large sections. Make sure the code is not used. Please delete it in time.
6. Update the code style based on the Code copied from other projects and delete unused code in time.
7. All Group or file names (image names) in the project. Do not use Chinese characters for naming. Try to use English letters for naming. Chinese characters can be used for special Chinese terms.
8. All groups in the project must have a real directory in the project directory. The files in the Group correspond to the files in the real directory one by one.
9. write comments of necessary code in the project.
10. Use # pragma mark-Mark Name to group methods. For example:
* # Pragma mark-View lifeCycle
* # Pragma mark-View lifeTerm
* # Pragma mark-Init methods
* # Pragma mark-Action methods
* # Pragma mark-Common methods
* # Pragma mark-UIActionSheetDelegate
* # Pragma mark-UIImagePickerControllerDelegate
* # Pragma mark-UITableViewDelegate Methods
* # Pragma mark-UITableViewDataSource Methods
* # Pragma mark-UIScrollViewDelegate Methods
* # Pragma mark-UITextFieldDelegate Methods
* # Pragma mark-UITextViewDelegate Methods