Each company has a code specification for each company, learn to record the new company iOS code specification:
name
Naming rules are very important for maintaining code, and clear and concise naming is good for teamwork. In general, don't use the abbreviations of words. Except for the very common abbreviations, try to use the full names of words. API names should not be ambiguous. Here are the naming conventions:
1.1. Naming Do not use generic vague names, exact names, do not abbreviate names or names with single letters.
1.2. Elegant naming: refer to public func stream(withHostName hostName: String, port: Int) -> StreamRequest in Almofire.
1.3. Type names are named in big camel case, and variables and constants are named in small camel case. Do not use any Hungarian notation (eg: k for constant, m for method), use short names and use Xcode's Type Quick Help (01.png+ click) to find out the type of the variable. Likewise, don't use lowercase + underscore ( SNAKE_CASE ).
1.4. To avoid repeated words in naming, please refer to the official swift documentation, as follows:
// Swift 3 definition
prepare(for segue: UIStoryboardSegue, sender: Any?)
// Swift 3 calling code
viewController.prepare(for: segue, sender: something)
1.5. The parameters with default values in the func name are placed at the end.
1.6. Define the format of the parameter labels passed in and returned by each func, and try to write them in the swift specification format, so that the code structure is clearer, and it is convenient for yourself and others to maintain and read.
{E.g:
(message : T, file : String = #file, lineNumber : Int = #line, FuncName: String = #function)
instead of
(message:T,file:String=#file,lineNumber:Int=#line,FuncName:String=#function)
Watch out for spaces, commas, colons, and newlines, especially spaces!
}
1.7. Image names should be uniformly named to maintain the integrity of the organization. They should be named with a camel-cased string describing their purpose, followed by the unprefixed name of the custom class or property (if any), then further describing the color and/or placement, and finally their state. E.g:
RefreshBarButtonItem / RefreshBarButtonItem@2x 和 RefreshBarButtonItemSelected / RefreshBarButtonItemSelected@2x
ArticleNavigationBarWhite / ArticleNavigationBarWhite@2x 和 ArticleNavigationBarBlackSelected / ArticleNavigationBarBlackSelected@2x.
method
2.1. The constructor can be called directly using the class name +. form Example: NoticeinfoModel(responseData: JSON) No need to write init ( NoticeinfoModel.init(responseData: JSON) ).
2.2. When parsing, the web framework will be converted to SwiftyJSON, so try to use stringValue to prevent data from being empty when parsing.
Class Code Organization Principles
One principle: the destructor deinit is best placed at the top of the class. You can see this method at first glance, and you can easily see whether some operations have been removed, the reasonable release of memory, etc. The life cycle functions of controller and view are placed To the top, the methods implemented by yourself are below, and the methods with the same/similar functions are marked with #pragma mark - for easy viewing.
Notes
When needed, comments should be used to explain why particular code does something. Any annotations used must be kept up to date or deleted.
A large block of comments should generally be avoided, and the code should be used as its own documentation as much as possible, with only a few lines of explanation. This does not apply to annotations used to generate documentation.
3.1. Some closures that cannot reflect their functions need to be annotated.
The variables in 3.2.model need to be annotated.
3.3. The enumeration type returned by the server needs to be annotated. Do not use magic number to identify the value of a variable.
file structure
The iOS project file structure is divided into physical structure and logical structure. It is recommended that the logical structure and physical structure be consistent, so as to manage class files conveniently and effectively. In actual use, the actual person in charge of the project can use it flexibly in combination with the characteristics of the project, but the basic principles must be maintained, and a good class file organization structure must be maintained.
4.1. It is recommended that a file should not exceed 1500 lines.
4.2. It is recommended that a function or method should not exceed one screen.
4.3. Useless code, including Xcode-generated template code and placeholder comments, should be removed unless it is purposefully preserved. Some methods simply call the methods in the parent class and also need to be deleted.
4.4. It is recommended to extract the view in the contorller, and do not couple the model in the view.
4.5. It is recommended to use private to modify the control in the view, and use the method to modify the value of the control in the view.
4.6. Use MARK to segment the code with a clear structure.
Swift usage specification
5.1. For brevity, the self keyword can be avoided.
5.2. The use of spaces shall refer to the standard apple sample code and shall be used uniformly.
5.3. Reasonable use of private and fileprivate, private is recommended, and fileprivate can be used when using extension.
5.4. The ?? method can be used when it is not certain whether the data is empty or not, such as print(str ?? "").
5.5. Swift native types are preferred, and methods provided by Objective-C can be used as needed.
5.6. Use a trailing closure expression only if the closure expression parameter is last in the parameter list. Closure parameter names should be descriptive.
5.7. When using an array, you can specify the element type Example: var noticeArr = [JSON]() If no instantiation is required, var noticeArr : [JSON]? .
5.8. Use shared for singletons (don't use other names like shareInstance, shareClient).
Xcode project
6.1. Use the showInFinder form to actually create the file and drag it into the project.
6.2. Add the corresponding files in xcassets according to the project module structure. Do not drag the pictures into xcassets separately. To delete pictures, you need to delete them in xcassets to ensure that the json corresponding to the pictures is also deleted.
6.3. To avoid file clutter, physical files should be kept in sync with Xcode project files. Any group created by Xcode must have a corresponding mapping on the file system.
6.4. For clarity, code should be grouped not only by type, but also by function. If possible, keep "Treat Warnings as Errors" and some additional warnings turned on in the target Build Settings as much as possible. If you need to ignore specific warnings, use Clang's compilation features.