Android Encoding Specification

First, naming specification 1.1 package naming

Naming rules: A unique package name is always prefixed with all lowercase ascii letters and is a top-level domain name, typically com,edu,gov,mil,net,org, and so on.

Statute: The company shall prevail. This is usually the name of the COM company. Abbreviation for project names. Module or hierarchy name

1.2 Class and interface naming

Naming rules: The class name is a noun. Use uppercase and lowercase blending methods. Capitalize the first letter of each word. Avoid using abbreviations. Unless the acronym is more widely used, such as url,html.

Interface name, beginning with the capital letter I. Capitalize the first letter of each word.

1.3 Method naming

Naming rules: The method name is a verb. In uppercase and lowercase combinations, the first letter is lowercase. Capitalize the first letter of all subsequent words

The Fetch method for the 1.3.1 class (typically with a return value) generally requires a get in front of the field name being interviewed.

In general, the Get prefix method returns a single value. The Find method returns a list value.

The setting method for the 1.3.2 class (the general return value is void) is preceded by the Access field name plus set

A Boolean inference method for the 1.3.3 class generally requires that the method name be prefixed with the word is or has, or use a logical word, such as equal or equals.

The general method of the 1.3.4 class generally uses the full description of the English description of the member method function, the first word as far as possible verbs. First Letter Lowercase

The 1.3.5 construction method should be written in increments of the number of parameters written in the back.

1.4 Variable naming

Naming rules: The first letter is lowercase. Capitalize the first letter of the subsequent word. Variable names should not begin with an underscore or dollar sign, although this is syntactically agreed. Try to avoid variable names for individual characters. Unless it is a one-time temporary variable. Temporary variables are usually named I,j. K. M and N, which are generally used for integral types, C. D,e. They are generally used for character types. The variable name does not agree to the occurrence of meaningless words.

1.5 member variable naming

Name the same variable, but add the letter m before the member variable, with the letters beginning with uppercase, for example Medithours.

Add the words "s" before static variables. The following letters start with uppercase, for example Sedittime.

1.6 Constant naming

Naming rules: Declaration of class constants, should be all uppercase, separated by underscores between words.

1.7 Exception naming

Rule: The name of your own definition exception must end with exception. With a clear mark as an exception.

1.8Layout naming

Statute: Layout XML naming must be in all words lowercase, the word between the underlined cut, and using a noun or noun phrase, that is, using the module name _ function name to be named.

1.9 ID Name

Statute: The ID used in layout must be lowercase in all words. The words are underlined, and nouns or noun phrases are used, and the functions that the current component implements can be directly understood by the ID.

1.10 Resource Naming

Statute: All resources used in layout (such as Drawable,style, etc.) must be named with all words in lowercase. The words are underlined, and as far as possible the use of nouns or noun groups, that is, using the module name _ use to name. Assumed to be a public resource. such as cutting lines, etc., are directly used to name the use.

Second, the gaze norm

The proportion requirement of the code is 30%, the gaze language must be accurate, easy to understand and concise.

Java programs have two types of gaze: implementation Gaze (implementationcomments) and document Gaze (Doc comments). Realization Gaze is the use of/*...*/and//defined gaze. Document Gaze (referred to as "Doc comments") is defined by/**...*/. Document gaze can be converted to an HTML file using the Javadoc tool.

2.1 File Gaze

The head of the source file should be stared, listed: Copyright description, version, module purpose/function, author, date of creation, changelog, etc.

File Header Template:

/**

* @Title: ${file_name}

* @Package: ${package_name}

* @Description: ${todo} (describe what the document does in a word)

* Copyright:

* Company:

*

* @author ${user}

* @date ${date} ${time}

* @version V1.0

*/

Description: The document describes a description of the contents of this document, the function of the internal parts of the relationship between the document and other documents and other relations.

Class 2.2 Gaze

Each class includes a gaze, such as the following format, to illustrate the functionality of the current class.

/**

* @ClassName: ${type_name}

* @Description: ${todo} (here is a word describing the role of this class)

* @author ${user}

* @date ${date} ${time}

*

* ${tags}

*/

2.3 Method Gaze

Each public method includes a gaze such as the following format, including the purpose of the current method, the meaning of the current method parameter, the contents of the current method's return value, and a list of thrown exceptions.

/**

* @Title: ${enclosing_method}

* @Description: ${todo} (here is a word describing the role of this method)

* @param: ${tags} Name of the participant

* @return: ${return_type} return type

* @throws

*/

2.4 Class members and variable gaze

member variables and constants need to use the Java Doc form of gaze to illustrate the meaning of the current variable or constant.

/**

* @Fields ${field}: ${todo} (describe what this variable means in a word)

*/2.5 Code Gaze

2.5.1 Change the code should change the corresponding gaze

2.5.2 gaze should be similar to the code described in the description, not to be placed in the following, if placed above the code with the above is separated by a blank line.

2.5.3 the gaze of the data structure should be placed in the adjacent position above it. Do not place the following. The gaze on each field in the structure is placed to the right of this field.

2.5.4 helps the reader understand the code and prevents the repetition of gaze information that is not required.

2.5.5. When the code snippet is long, especially when multiple nesting. Gazing makes the code clearer and easier to read.

2.6 Changing the gaze of an existing class

Changes to existing classes need to be included in the revision record, such as the following. Add revision record, change content, review record three lines after blank line.

2.7 Changing the code gaze

2.8XML Gaze

Statute: Assume that the current layout or resource needs to be called in multiple places, or as a public-used layout (if list_item). You need to specify the gaze in XML. Require gaze to be clear and understandable.

2.9Code Review Gaze

2.10 Other Gaze

The gaze assumptions inside the method need to be multiple lines using/* ..../form, assuming that a single line is used//... form of gaze.

Do not approach the internal use of the Java doc form of gaze "/**......**/", the simple way to distinguish is that the Java doc form of gaze in eclipse blue, the normal gaze is green.

Three, code style 3.1 indentation

Statute: Do not agree to indent using tab. Use spaces to indent. The recommended indent is 4 spaces.

3.2 Blank Line

You should always use a blank line in the following situations:

1. Between two fragments (sections) of a source file

2. Between class declaration and interface declaration

Between 3 and two methods

4. Between the local variables in the method and the first statement of the method

5. Between two logical segments within a method to improve readability

Statute: A blank line is usually separated after the variable declaration area. A constant declaration area is separated by a blank line. A blank line is delimited before the method declaration. 3.3 Line width

There is no special requirement, since the display is now relatively large, it is recommended to use 120 to set.

IV. Specification Agreement

4.1 Methods

A method should try not to exceed 15 rows, assuming that the method is too long, indicating that the current method of business logic is already very complex, then the method needs to be split, to ensure that each method is only one thing.

4.2 Number of references and return values

The number of participants in a method should be as little as 4.

You can use Collections.emptylist () instead of NULL, as an exception, or with an empty variable, such as returning a List.

4.3 Phantom Numbers (parameters and return values)

Individual numbers are not accepted in the code. Character! Suppose you need to use numbers or characters. They are encapsulated as static constants according to their meanings! (except in the For statement)

4.4 Control Statements

If there are constants in the inference, the constants should be placed on the right side of the inference.

Try not to use nesting of three-mesh conditions.

All if statements must be included with {}, even if there is only one sentence.

4.5 Exception capture

If there is a finally clause. Do not return directly in the try block, nor in finally.

4.6 Access control Five, the conventional 5.1 variable assignment

Avoid assigning the same value to multiple variables in a single statement.

Do not use assignment operators in places where easy is confused with equality operator.

Do not use the inline (embedded) assignment operator to try to improve execution efficiency, which is the work of the compiler.

5.2 Parenthesis 5.3 return value

Try to make your program structure conform to the purpose.

5.4 Two-tuple expressions

Suppose an expression that includes a two-dollar operator is now a ternary operator "? : "The"?

Before Then you should add a pair of parentheses to the expression.

Six, 21 kinds of code bad taste

1.Duplicated Code Repeat Codes

2.Long method over-length function

3.Large class is too large

4.Divergent Change divergence

5.Shotgun surgery, loose-elastic change

6.Feature Envy Dependency Complex

7.Data Clumps Data Mud Regiment

8.Primitive Obsession Basic Type Paranoia

9.Switch Statement Multi-Branch selection statement

10.Parallel Inheritance hierarchies parallel inheritance system

11.Lazy class redundant

12.Speculative generality rhetoric of the future

13.Temporary Field confusing temporary range

14.Message Chain over-coupled message chain

15.Middle Man in Middle hands

16.Inappropriate Intimacy Contempt relationship

17.Alternative Classes with Different Interfaces similar class

18.Incomplete Library class is not intact program libraries

19.Data Class Pure Data classes

20.Refused Bequest rejected Bequest

21.Comments Too much stare

Android Encoding Specification