Swift Programming Specification

Document Number:

Application Development Swift Coding specification

(Version v1.0.0 )

Written information
Subject headings:		Code specification for Swift development
Author		Week less Stop	Document Category:			Development specifications
Audit
Approved			Document Nature:			Draft
Main delivery:			Archive Date:
cc			Release Date:			April 8, 2016
Change information
Version	Reason			Author	Date

Chapter I overview 1.1 preparation purposes

The purpose of development specification is to ensure that in the process of system design, coding, testing and maintenance, project team members follow a set of unified system design standards, application writing standards, page style standards,

To improve the efficiency of the software development team, increase the unity of code, readability, maintainability, and ensure the stability of the project development.

The reader for this document is a developer.

This document provides the specifications and guidelines for project development. Developers must strictly adhere to this development specification during the development process.

1.2 Definitions

Base class: The application's bottom-level program support, encapsulating the application's basic functionality and framework implementation.

All the content under the standard headings in this article are the conventions that must be adhered to in the development process.

The content under the headings of attention in this article is the best principle in the development process, and they are many tips to improve the performance of the application and to avoid unnecessary errors.

1.3 References

To learn more about Swift, please refer to the following links:

GitHub official website: https://github.com/

Apple Swift official website: https://developer.apple.com/swift/

Swift Learning website (SWIFTV video classroom): http://www.swiftv.cn/

Swift Learning website (Geek College): Http://search.jikexueyuan.com/course/?q=swift

Swift Guide: Https://github.com/ipader/SwiftGuide

Swift Code specification: HTTPS://GITHUB.COM/ARTWALK/SWIFT-STYLE-GUIDE/BLOB/MASTER/README_CN.MD

Https://github.com/raywenderlich/swift-style-guide

Chapter two code format and style 2.1 Basic principles

Code format and style of the basic principles are: easy to develop, easy to communicate, consistent, in line with this specification, the formation of a unified style throughout the company.

• Indentation accuracy, reducing the likelihood of programmers making mistakes
• Explicit intent
• Reduced redundancy
• A small amount of discussion about beauty

2.2 New Project

• Product name in English with the first initial letter capitalized
• Organization Name:9elephas
• Organization Identifer:com.9elephas

2.3 Indent

A child function block is indented after its parent function block.

When the function block is too large to cause the indentation to be too deep, the child function block is extracted as a child function.

• Use Tabs, not spaces
• Leave a blank line at the end of the file
• Divide the code into reasonable chunks with enough empty lines
• Don't leave a blank at the end of a line
• Never leave a indentation in a blank line

Use indents of 2 spaces instead of tabs to save space and help prevent line breaks. Be sure to set this preference in Xcode.

Such as:

2.4 Length

For readability and comprehension, the effective code length of a single function is as much as possible within 100 lines (excluding comment lines), and when a function module is too large it often causes difficulty in reading,

Therefore, when using sub-functions and so on to extract the corresponding functions, which also helps to improve the reuse of code.

A single class should not be too large, and when such a situation occurs when the code of the corresponding function is refactored into another class, called by a combination, it is recommended that the length of a single class include no more than 1500 lines of comment lines.

Try to avoid using large classes and long methods.

2.5 line width

The page width should be set to 80 characters. Generally do not exceed this width, which can cause a screen to be completely displayed on some machines, but this setting is also flexible.

In any case, an extra-long statement should be wrapped around a comma or before an operator. When a statement is wrapped, it should be indented a tab or 4 more spaces than the original statement for readability.

A line of code length is also best controlled within 80 characters, this function can be set in Xcode.

2.6 Intervals

Classes, methods, and function blocks should be separated by empty lines to increase readability, but there should be no irregular tracts of empty lines.

Each end of the operator should be empty one character to increase readability.

The corresponding independent function modules can use the comment line interval and indicate the corresponding content.

2.7 Brackets

Swift brackets differ from other programming languages, which you need to be aware of.

At the same time, the use plan for {} should be:

Instead of

2.8 Semicolon

Swift does not need a semicolon to wrap, so at the end of each line of code, it is best not to add a semicolon, unless there are two lines of code on the line, then you need to add a semicolon after each code end

However, it is not recommended to write multiple lines of code on a line.

Chapter III Note 3.1 Basic principles

• Comments should increase the clarity of the code. The purpose of the code comment is to make the code easier to understand by other developers.
• If your program isn't worth commenting on, it's probably not worth running.
• Avoid the use of decorative content.
• Keep the annotations concise.
• Note Information should include not only the functionality of the code, but also the cause.
• Do not comment on the comment.
• Comments for shorter statements, such as variable definitions, are available in line-end annotations, while other comments avoid using end-of-line annotations.

3.2 Single-line comment

Single-line comment use//CAN

3.2 Multi-line comments

Multi-line annotations using/**/

Such as:

3.3 Types of annotations

At the beginning of each class, Xcode automatically writes about the class. The project's information needs to be commented on: The function of the class. Precautions, etc.

3.3 Method Comments

Write a comment for each method, the function of the method. Precautions, etc., using the mark mark.

The fourth Chapter field 4.1 class name. Custom protocol name. Enumeration

The class name. The name of the custom Protocol. Enumeration using the big hump naming method, the first letter of each word of the class name should be capitalized. For example:

4.2 Method name.

The name of the method. The protocol name uses the small hump name method. The first letter is lowercase and the first letter of the remaining words is capitalized.

4.3 variable name. Constant name. The name of the collection.

Variable name. Constant name. The collection name is used for the small hump naming method, if there is only one word, all lowercase.

4.4 Type Inference

尽可能地使用Swift原生类型.如:

应尽量避免:

4.5Calculated properties

To keep it simple, if a computed property is read-only, ignore the Get statement. A Get statement is provided only when a set statement needs to be defined.

Recommended:

Not recommended:

4.6函数声明

保证短的函数定义在同一行中，并且包含左大括号：

In a long function definition, wrap the line where appropriate and add an extra indent to the next line:

4.7 Closed-Packet expressions

If the closure expression argument is the last in the argument list, a trailing closure expression is used. A descriptive name for the given closure parameter.

Recommended Practice:

Not Recommended Practice:

When the context of a single closure expression is clear, an implicit return value is used:

4.8 Structure Builder

Using the native Swift struct constructor is better than the old-fashioned geometry class (Cggeometry) constructor.

Recommended:

Not recommended:

4.9 Grammar sugar

It is recommended to use a simple version of a type definition rather than a universal syntax.

Recommended:

Not recommended:

4.10 Control Flow

It is recommended to use for-in expressions instead of for-condition-increment expressions.

Recommended:

Not recommended:

The fifth Chapter 5.1. can be used letTry to use letInstead of var

A good trick is to use let to define anything and change to the VAR definition only when the compiler tells us that the value needs to be changed.

5.2. Early and ReturnOr break

When you encounter certain actions that need to be performed by condition judgment, you should exit the judging condition as soon as possible, such as

and should not

5.3. Avoid strong unpacking of optional types 5.4. When you specify a type, the colon and the identifier are joined together

When specifying the type of the identifier, the colon is followed by the identifier, and then the empty one is written in the type

5.5. Write when needed selfJust write it when you need it. self,当调用 self 的 properties 或 methods 时，self 用默认的隐式引用：

When necessary self , add, for example, in closures, or in conflict with the name of the parameter:

5.6. Preferred structsRather than classes

Unless you need class to provide functionality (such as identity or deinitializers ), usestruct

It is important to note that inheritance is not usually a good reason to use classes, because polymorphism can be implemented through a protocol, and reuse can be implemented by combination.

For example, the classification of this class

Can be re-constituted this way:

5.7. Leave the Action definition blank

When you define an action definition, leave the sides blank

Recommended

A = B + +

Not recommended

a=b++

Swift Programming Specification