Android code specification and android code specification

Android code specification and android code specification
I. Naming rules 1.1 packages

Naming rules: the prefix of a unique package name is always all lowercase ASCII letters and is a top-level domain name, usually com, edu, gov, mil, net, org, etc.

Statute: Subject to the company, generally com. Company Name. Project name abbreviation. Module name or level name

1.2 class and interface naming

Naming rules: a class name is a noun. It is a combination of upper and lower cases. The first letter of each word is capitalized. Avoid using acronyms unless they are more widely used, such as URLs and HTML.

Interface Name. It starts with an uppercase letter I and starts with an uppercase letter.

1.3 method naming

Naming rules: the method name is a verb. It is case-sensitive. The first letter of the first word is lowercase, and the first letter of all subsequent words is capitalized.

1.3.1 class obtaining methods (usually return values) generally require that you add get before the accessed field name. Generally, the get prefix method returns a single value, and the find method returns a list value.

1.3.2 class setting method (generally the return value is void) added before the accessed field name

1.3.3 Boolean judgment methods of the class generally require the method name to use the word is or has as the prefix, or use words with logical meaning, such as equal or equals.

1.3.4 common methods of the class generally use the complete English description to describe the member method function. The first word should use a verb as much as possible, and the first letter should be lowercase.

1.3.5 The constructor should be written in ascending mode, that is, there are many parameters.

1.4 variable naming

Naming rules: the first letter of the first word is in lowercase, and the first letter of the subsequent word is in uppercase. Variable names should not start with an underscore or dollar sign, although this is syntactically allowed. Avoid the variable name of a single character unless it is a one-time temporary variable. Temporary variables are usually named I, j, k, m, and n. They are generally used for integer type; c, d, e, they are generally used for struct type. Variable names cannot contain meaningless words.

1.5 member variable naming

The name is the same as that of the variable, but the m character must be added before the member variable, followed by a letter starting with an uppercase letter, such as mEditHours.

Add the word "s" before the static variable and start with an uppercase letter, for example, "sEditTime.

1.6 constant name

Naming rules: the Declaration of class constants should be in uppercase and words should be separated by underscores.

1.7 abnormal naming

Rule: The name of a custom Exception must end with Exception. It is clearly marked as an exception.

1.8Layout name

Naming Conventions: layout xml names must be in lowercase for all words. The words are separated by an underscore (_) and are named by a noun or a noun phrase.

1.9 ID name

Conventions: the IDs used in layout must be in lowercase for all words. The words must be separated by an underscore (_) and nouns or phrases are used. You must be able to directly understand the functions of the current component through the id.

1.10 Resource naming

Conventions: the names of all resources used in layout (such as drawable and style) must be in lowercase for all words. The words must be separated by a line below, and nouns or noun groups should be used as much as possible, that is, the module name_purpose is used for naming. If it is a public resource, such as a split line, it is directly named by the purpose.

Ii. annotation specifications

The ratio of interpretation to code must be 30%. The annotation language must be accurate, easy to understand, and concise.

Java programs have two types of Annotations: implementationcomments and document comments ). Implementation comments are comments defined using/*... * // and. Document comments (known as "doc comments") are defined. You can use javadoc to convert document comments into HTML files.

2.1 file comment

The source file header should be annotated to list: Copyright description, version number, module purpose/function, author, generation date, modification log, etc.

File Header template:

/**

* @ Title: $ {file_name}

* @ Package: $ {package_name}

* @ Description: $ {todo} (describe the file in one sentence)

* Copyright:

* Company:

*

* @ Author $ {user}

* @ Date $ {date }$ {time}

* @ Version V1.0

*/

Description: This document describes the content and functions of this document, the relationship between the internal parts, and the relationship between this document and other files. 2.2 class annotations

Each class must contain annotations in the following format to describe the functions of the current class.

/**

* @ ClassName: $ {type_name}

* @ Description: $ {todo} (Here we use a sentence to describe the role of this class)

* @ Author $ {user}

* @ Date $ {date }$ {time}

*

* $ {Tags}

*/

2.3 method comments

Each public method must contain annotations in the following format, including the purpose of the current method, the meaning of the current method parameter, the content returned by the current method, and the list of thrown exceptions.

/**

* @ Title: $ {enclosing_method}

* @ Description: $ {todo} (Here we use a sentence to describe the role of this method)

* @ Param: $ {tags} parameter name

* @ Return: $ {return_type} return type

* @ Throws

*/

2.4 class member and variable comments

Member variables and constants must be annotated in the form of java doc to describe the meaning of the current variable or constant.

/**

* @ Fields $ {field }:$ {todo} (describe in one sentence what this variable represents)

*/2.5 code comments

2.5.1 the corresponding comments should be modified when the code is modified.

2.5.2 comments should be similar to the code described, and should not be placed below. For example, they should be separated from the code above by blank lines.

2.5.3 comment on the data structure should be placed in the adjacent position above it and cannot be placed below; comment on each field in the structure should be placed on the right side of this field.

2.5.4 helps readers understand the code and prevent unnecessary comments.

2.5.5. When the code segment is long, especially multiple nesting, annotations can make the code clearer and easier to read.

2.6 modify comments of existing classes

To modify an existing category, you need to add a revision record, as shown in the following figure. Leave a blank row and add three lines: Revision record, modification content, and Review record.

2.7 modify code comments

2.8XML Annotation

Protocol: if the current layout or resource needs to be called in multiple places, or the layout (if list_item) for public use, you need to write comments in xml. Annotations are clear and easy to understand.

2.9 Code Review comments

2.10 Other annotations

Comment inside the method. If you need to use multiple lines /*...... */Format. If it is a single row //...... Annotations. Do not use the java doc Format to comment "/**... **/", The simple differentiation method is that the notes in java doc form are blue in eclipse, and the normal annotations are green.

Iii. Code style 3.1 indent

Conventions: Tab indentation and space indentation are not allowed. It is recommended that four spaces be indented.

3.2 blank lines

Empty rows should always be used in the following cases:

1. Two sections of a source file

2. Between class declaration and interface declaration

3. Between Two Methods

4. Between the local variable in the method and the first statement of the Method

5. Two Logical segments in a method to improve readability

Conventions: Generally, empty rows must be separated after the variable declaration area. Empty rows must be separated after the constant declaration area, and empty rows must be separated before the method declaration. 3.3 rows wide

There is no special rule, because the current display is relatively large, so we recommend that you use 120 for settings.

IV. Provisions

4.1 Method

A method should not exceed 15 rows. If the method is too long, it indicates that the business logic of the current method is very complicated. You need to split the method to ensure that each method only performs one thing.

4.2 parameters and return values

The maximum number of parameters for a method is 4.

Do not use null as much as possible. You can use Collections. emptyList () to replace it with an exception or use an empty variable. For example, if List is returned ().

4.3 ghost number (parameters and return values)

Separate numbers and characters are not allowed in the code! To use numbers or characters, encapsulate them as static constants according to their meanings! (Except for the for Statement)

4.4 control statements

If a constant exists, the constant should be placed on the right side of the limit expression.

Try not to use the nesting of the Three-object condition.

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

4.5 exception capture

If a finally clause exists, it is not returned directly in the try block or in finally.

4.6 Access Control 5. It is customary to assign a value to a variable of 5.1.

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

Do not use the value assignment operator in areas that are easily confused with equality operators.

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

5.2 parentheses 5.3 Return Value

Try to make your program structure fit your purpose.

5.4 binary expressions

If an expression containing binary operators appears in the ternary operator "? "? "Before, you should add a pair of parentheses to the expression.

6. 21 bad codes

1. Duplicate Duplicated Code

2. Long Method function is too Long

3. The Large Class is too Large.

4. Divergent Change

5. Shotgun Surgery Modification

6. Feature Envy dependency Complex

7. Data Clumps Data dashboard

8. Basic Primitive Obsession type paranoia

9. Switch Statement multi-branch selection Statement

10. Parallel Inheritance Hierarchies Parallel Inheritance System

11. Lazy Class redundancy Class

12. Speculative Generality exaggerated the future

13. Confusing Temporary value Field

14. Message Chain over-coupled Message Chain

15. Transfer between Middle Man

16. Inappropriate Intimacy relationship

17. Alternative Classes with Different Interfaces similar class

18. Incomplete Library Class imperfect program Class Library

19. Data Class pure Data Class

20. Rejected Bequest

21. Too many Comments

According to the Android code specification, m must be added before the private member variable in the class?

There is no standard for this.
In general, private or protected member variables, and methods all start with _, without the type prefix, are named by the meaning string.
For example, two textviews are the title and one is the user name.
Private TextView _ title;
Private TextView _ userName;
One way to get the user name
Private String _ getUserName ();

The Hungary markup method with the type prefix is not suitable for java environments. For java development, it is not necessary to differentiate types by prefix. Therefore, distinguishing meanings is more important.

Total or package permissions are not added _,
Public String dummy;
Public String getCurrentUser ();

In this way, you can understand what it means and save comments.

Android system package naming rules

Generally, it is com. Company Name. Package name. Although my company is not big, old engineers are like this. Try to let people know your name and read less comments.