1. Overall
Guiding PrinciplesThe rules1-1 "The first is to write the program, followed by the computer.
Note: This is the basic point of software development, software life cycle throughout the product development, testing, production, user use, version upgrades and maintenance of the long-term process, only easy to read, easy to maintain the software code to have vitality, so the promotion of writing code before thinking more , especially where the logic is complex or the technical difficulty is high, personal thinking is not clear, and the team members can communicate.
The rules1-2 "Keep your code concise and clear and avoid excessive programming skills.
Description: Simple is the most beautiful. Keeping the code simple is the basic requirement of software engineering. Don't overdo it, or it will reduce the readability of your program.
The rules1-3 "When programming the first to achieve correctness, and then consider the efficiency.
Description: The first consideration in programming is to satisfy the quality factors of correctness, robustness, maintainability, portability , and finally to consider the efficiency and resource consumption of the program.
The rules1-4 "When writing code, consider the testability of your code.
Description: code that cannot be tested is not guaranteed quality, and developers should keep this in mind to design and encode. While implementing the design functionality, provide a method that can be tested and validated.
The rules1-5 "function (method) is written for a specific function, not a universal toolbox.
Description: The method is a processing unit, there is a specific function, so should be well planned method, not everything is put in a method to implement, and can not put everything in a class to implement (for example, VC).
The rules1-6 "
encourage more comments .
Rule 1-7 recommends less use of xib, especially constraints in Xib .
2. Controller Specification "rules2-1 "No external methods and properties are required and
must not be defined in the header file (. h).
The API that is provided externally in the "rule 2-2" header file is recommended in the way of method parameters and is not recommended in the way that attributes are used.
Note: This is because of the way the property is used, if the controller calls more places, the parameters of each place are different, it will cause the caller property assignment confusion.
The rules2-3 "It is not recommended to call the network request (hdfnet) directly in the controller and perform data processing.
The "rule 2-4" Controller generally carries more logical processing, so the file structure of the controller is as follows:
File header #import (standard library header file, nonstandard library header file) macro defines a global data type class definition
file Header #import (standard library header file, nonstandard Library header file) the implementation of a global variable local variable (that is, a static global variable) class using the data type used internally within the macro file #pragma mark-lifecycle#pragma mark-private Method#pragma mark--UI#pragma mark-- Data loading and parsing #pragma mark-event#pragma mark-delegate#pragma mark-Uitableviewdatasource# pragma mark--uitableviewdelegate#pragma mark-getter/setter
The rules2-5 "blank line. A blank line between each item in rule 2-4, a blank line between methods, and an empty line between the important code segments. 3. Naming conventions "Rule 3-1 "All file names need to be prefixed. the "Rule 3-2" Business Module
recommends Customizing a prefix, such as a family doctor, that can be prefixed with hdffamilydoctor. "Rule 3-3 "naming follows the Hump method naming rules.
Description
- Small Hump Method: In addition to the first word, the first letter of the other words capitalized;
- Big Hump Method: Capitalize the first letter of the initial word.
"Rule 3-4 "class naming follows the big hump rule:
prefix + description + type .
Description: take the Family Doctor Service page For example, the prefix is hdffamilydoctor, described as service, type Viewcontroller, Then the class is named Hdffamilydoctorserviceviewcontroller.
For types, there are several main categories:
| Description |
type |
| Controller |
Viewcontroller |
| Table row |
Cell |
| View |
View |
| Model |
Model |
| Data request |
Datahelper |
"Rule 3-5 "attribute naming follows small hump rule:
description + type shorthand
Description: For example, define a name for the label, described as name, type label, named Namelabel.
There are two major categories of type abbreviations:
I. Type of foundation
Foundation type |
Abbreviation |
| NSString |
String |
| Integer/int |
Int |
| Bool/boolean |
Bool |
| Char |
Char |
| Nsarray |
Array |
| Nsdictionary |
Dic |
| NSDate |
Date |
| NSObject |
Obj |
Ii. Types of Uikit
| Uikit Type |
Shorthand |
Uikit Type |
Shorthand |
| UILabel |
Label |
UIButton |
Btn |
| Uitextview |
TextView |
Uitextfield |
TextField |
| UITableView |
TableView |
Uiimageview |
ImageView |
| UIWebView |
WebView |
Uiscrollview |
ScrollView |
| Uiviewcontroller |
Vc |
UITableViewCell |
Cell |
"Rule 3-6 "method named following the small hump rule, it is recommended to abide by the following relevant rules:
- The names of the methods should all use meaningful words, read like a complete sentence, can let a person from the name can know the role of the method;
- You do not need to add a get before the Set method needs to add the Set,get method;
- Common methods of naming should use the agreed verbs, such as initwith, insert, remove, replace, etc.
- The Init method should follow the Apple naming convention, with the return type using instancetype instead of the ID;
- In the method signature, there should be a space after the method type (-/+ symbol ) . There should also be a space between the various segments of the method.
"Rule 3The following format is recommended for 7 "enum type type and enumeration value naming:
typedef ns_options (Nsinteger, Masattribute) { 1 << nslayoutattributeleft, 1 << nslayoutattributeright};
"Rule 3-8 "Picture naming Adoption Rules:
module + function + type
Description
- Modules can be divided into public modules and private modules, can be customized abbreviation of the module, such as the Common module navigation bar, can be defined as NAV;
- function according to the specific purpose of the division, such as the return button, function can be positioned as back;
- Types are mainly available in several categories: such as background (BG), button (BTN), and so on.
In summary, if it is the return button of the navigation bar, it can be named [email protected].
4. Notes
The "Rule 4-1" comment recommends uniform use of the vvdocument plugin.
"Rule 4-2" each header file must be annotated to describe the functionality of the class.
The properties and methods defined in the "Rule 4-3" header file must be commented on .
Description: Comments on properties are recommended to use "//<!" after a property Add to.
"Rule 4-4 "to implement
variables, attributes, and custom methods defined in the file, you must add a comment .
Thesystem method or System agent in the "Rule 4-5" Implementation file does not force the comment to be added.
In the "Rule 4-6" Implementation file method, comments are added to the function segment code , such as the definition of a view and property settings, which can be added as a function segment.
Suggestions for "rule 4-7" Enumeration types, macro definitions, struct bodies, and so on.
IOS encoding Specification (simplified version)