iOS Development specification

Introduction

Before looking at the following, we have to self-test the code is written in the specification, code style is too different reading difficulties? Can read the companion's code to each other, is there dyslexia?

If there is an obscure, understanding of the cost-increasing code, your team needs introspection.

Here's a summary of some code specifications in OC programming (Apple's official recommendation). OC as an example, but not limited to OC, can also be used as a development specification for other programming languages (only need to use OC-specific things in the language you are using the Convention)

Reference: Description of the recommended code specification for the Apple Code specification

Named

Naming rules are important for maintaining code. Objective-c method names are often very long, but this also has the benefit of making many comments meaningless.

This article recommends hump method, which is also the standard of objective-c community.

The Hump method is divided into small hump method and large hump method. Small Hump method: Except for the first word, capitalize the first letter of the other word. The big hump method compares the small hump method, the big hump method has capitalized the first letter of the initial word.

1. Basic Principles

1.1 Clear

Clarity and brevity are the best, but brevity is not as important as clarity. In general, do not use the word shorthand, in addition to the very common shorthand, try to use the full name of the word. The name of the API should not be ambiguous, a look at your API will know in what way to do something, do not let people have doubts

1.2 Consistency

The code for doing something is usually called the name, such as tag, setstringvalue, and so do you. You can refer to some commonly used names when you are unsure how to name them:Method Arguments

2. Class naming

The class name (excluding categories and protocol names) should be capitalized with a large hump-named method. The class name should contain one or more nouns to describe what the class (or object of the Class) does.

In the application-level code, try not to use a prefixed class name. Each class has the same prefix that does not improve readability. However, if you are writing shared code between multiple applications, the prefix is an acceptable and recommended practice (type Jkphotobrowser).

Example 1:

@interface Imagebrowseview: UIView

@end

Example 2: (with prefix JK)

@interface Jkphotobrowser: UIView

@end

3. Category naming

class name + identity + extension ( Uiimageview +hp+web )

Example: if we want to create a Uiimageview-based category for a Web request picture, we should put the category

Put it in a file named Uiimageview+hpweb.h. Uiimageview for the class name to be extended, HP is the exclusive label

The web as an extended feature.

The methods of the class should all use a prefix (type such as hp_mycategorymethodonastring) to prevent objective-

C code conflicts in sole name space. If the code is not considered to be shared or in a different address space (address-

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

Category Hpweb header file, uiimageview+hpweb.h as follows:

@interface Uiimageview (hpweb)

-(void) hp_setimagewithurlstring: ( NSString *) Urlstr;

@end

4. Method naming

The method is named by the small hump method, and a canonical method reads like a complete sentence, and then knows the function after reading it.

's role. The method of execution should start with a verb, a lowercase letter, and a return method should return the content

Start, but do not add a get before.

Example:

-(void) Replaceobjectatindex: ( Nsuinteger ) Index Withobject: (ID) anobject;

(instancetype) Arraywitharray: ( Nsarray *) array;

If there are parameters, the function name should be the first parameter of the message, if there are multiple parameters, before the parameter should also have

Prompt information (usually without and)

Some classic operations should use the agreed verbs, such as initwith,insert,remove,replace,add and so on.

5. Variable naming

The variable name uses the small hump method, makes the variable name as far as possible to speculate its use attribute to have the descriptive nature. Don't think about a few dozen.

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

5.1 Class member variables:

Member variables are named with the small hump method and prefixed with an underscore, Objective-c 2.0, @property and @synthesize provide

A solution that follows a naming convention

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 naming

Constants (pre-defined, enumerated, local constants, etc.) use the Hump method that begins with lowercase k, such as Kinvalidhandle,

Kwriteperm

Example:

#define Krunannotationstartpointtitle @ " starting point "

typedef ns_enum (nsinteger,rungoaltypee) {

Krungoaltypenone = 0 ,     // No target

Krungoaltypetime = 1 ,     // take time as a target

krungoaltypedistance = 2 ,     // aim at Distance

Krungoaltypecalori = 3 ,     // aim to burn calories

};

NSString * Const Kgroupinfoname = @ "Name" ;

6. Image resource file naming

First look at the Sina Weibo app image resource naming method, the following is part:

This image resource naming method, to function as a form of organization, is a good habit, beneficial to view resource files.

Principle:

1) Use words to complete the spelling, or everyone is generally recognized non-discriminatory abbreviations (such as: NAV,BG,BTN, etc.)

2) using the "Module + function" Nomenclature, the module is divided into public modules, private modules. The public module mainly includes the unified back

View, navigation bar, label, public button background, public default diagram, etc.; private modules are based on the app's business

Function Module division, such as User Center, message center, etc.

Note: It is recommended that the background image be prefixed with BG, the button background is prefixed with BTN (no mandatory requirement, the project is actually

Responsible according to the characteristics of the team can be determined)

Examples of public module naming:

Navigation bar back Picture: [Email protected]

Navigate Back button: [email protected],[email protected]

Label Item background: [Email protected],[email protected]

Example of private module naming:

Take the Joggers app's User Center picture resource as an example to illustrate

Uc--user Center

User Center Avatar Default Image: [Email protected]

User Center top default background map: [Email protected]

User Center bottom background map: [Email protected]

This part of the work is more complicated, and in the programmer's mind will be considered a low-tech work, but the picture named

Rigor also reflects our pursuit of detail, the details of which determine success or failure.

Document organization structure

1. class file organization

The iOS project file structure is divided into physical and logical structures, and it is recommended that the logical and physical structures be consistent so that the class files can be managed efficiently. The class file organization follows two main principles:

Based on MVC design pattern principle, at least ensure controller and data processing, network request is relatively independent

Based on the function module principle, the function module includes the data/network processing, the UI front-end Interface two parts, the data/network processing should be in the data/network processing frame, but the UI front-end interface such as User Center, Message Center, their proprietary controller,view and so on should belong to the folder. You will also encounter some public view that can open up public folders to manage

In practice, the actual person in charge of the project can be used flexibly in combination with the project characteristics, but the basic principle must be maintained, and the organization structure of the class file should be maintained, which is good for the team.

2. Picture Resource file organization

Picture resource file, it is strongly recommended to use Images.xcassets management, as little as possible with the folder management you create.

The advantages of using images.xcassets a lot, specifically can read the relevant literature, here only from the project management point, in the Images.xcassets add picture resources, will not cause changes to the project file, and directly in the folder to add image files, each time the project file will be created Change, so using images.xcassets to manage picture resources can reduce the number of project conflicts.

is the file organization structure of joggers:

In strict accordance with the above discussion to organize the structure of the document, maintain the physical/logical structure of the unity, facilitate the team between

and shared resources.

Class Code organization principles

a principle: destructor-(void) Dealloc best placed on the top of the class, the first eye can see this method, you can easily see whether remove some operations, the reasonable release of memory, controller , the view's life cycle function is placed at the top, and the method of its own implementation below, the same/similar method is marked with #pragma mark-to see.

Example:

The first part mainly on easy to grasp, easy to promote, and the team development has a real help content for a brief discussion, mainly focused on naming, document organization principles, and gave the corresponding examples. The specification is carried out by the project leader in detail. Seems to forget something, yes, comments, the above does not have a special description of the comments, good code habits is a good comment, so here is not specifically for comments, comments are required by the project owner to agree.

iOS Development specification