Android Code specification

Android Code Specification

Review

To standardize the coding in Android projects, to facilitate the reading of the Code and to facilitate future maintenance, the specification is specially formulated. The following provisions are set out below from the gaze specification and code writing and naming conventions. In the source code in the name of the place is not standardized, I hope that we supervise each other, correct.

Annotation Specification naming specification JavaCode

Java Source code In addition to static constant definition should prohibit the use of underscores (_) as a variety of variables, functions, interfaces, class names and other named characters, the name should be used as far as possible without pinyin and pinyin abbreviations, and instead of the canonical English translation of the word name. Other specific naming conventions are as follows:

Package

the package name should consist of all lowercase words, should not contain uppercase letters, numbers, and other characters, and the word should be a complete word or canonical and recognized abbreviation.

Example:Com.zjhcsoft.mobile.survey

Class

the Class name should start with a capital letter, and the next word must begin with a capital letter.

Example:taskdetailactivity

Interface

Interface naming same class

Constant

All characters in a constant name must be capitalized, and a delimiter is used between the words using an underscore (_).

Example:connect_timeout

Variable

The name of the variable is divided into the following two ways:

Camel Sign Method : The first letter is lowercase, and the next word starts with a capital letter. Use this type of nomenclature for custom or infrequently used class objects ( except for the following types ).

Example:taskdetail

Hungarian flag Law: its basic structure is scope_typevariablename ( because We don't use global variables in Android, we generally omit scope ), which uses the 1-3 character prefix to represent the data type,the3 -character prefix must be lowercase, the suffix word is capitalized, and the other letters are lowercase. The prefix table is as follows:

BYTE b

Char C

Short sh

int I

Long L

string s

Float F

Double D

[] Arr

List LST

Vector V

StringBuffer SB

Boolean b

Byte b

Map map

Object ob

The following points should be noted when naming variables:

Select a meaningful name and note that the first letter of each word should be capitalized.

There are two values in a function that do not have a different meaning before and after the same variable is used.

I, j, K, etc. are only used as cyclic index variables for small loops.

Avoid naming state variables with flag.

Use is to name logical variables, such as: Blsfileisfound. By this method of naming Boolean variables, other developers can understand the meaning of Boolean variables more clearly.

If necessary, add a calculation qualifier at the end of the variable, such as: Cursalessum.

If you need to abbreviate variable names, be aware of the consistency of the abbreviation rules in all your code. We recommend that you try not to present abbreviations in variable names.
By placing a quantifier at the end, you can create more of the same variables, which are easier to understand and more easily searchable. For example, use Scustomerfirst and scustomerlast instead of using Sfirstcustomer and Slastcustomer. The commonly used quantifier suffixes are: first (one in a set of variables), last (the final of a set of variables), next (the next variable in a set of variables), Prev (the previous one in a set of variables), Cur (the current variable in a set of variables).
Choose the best data type for each variable, which reduces the need for memory, speeds up code fulfillment, and decreases the likelihood of errors. The data type used for the variable may affect the outcome of the variable being calculated. In this case, the compiler does not have a run-time fault, it simply forces the value to conform to the data type of the request. This kind of problem is extremely difficult to find.
Try to narrow the scope of the variable. If the scope of a variable is greater than it should be, the variable can persist and still occupy resources for a long time after the variable is no longer needed. The important problem with them is that any method in any class can fix them, and it's hard to keep track of where they were corrected after all. Seizing resources is a major concern in the scope. For variables, minimizing the scope will have a huge impact on the reliability of the application.

Domain variables

A domain variable generally refers to the variable used by the set/get method in the Bean , which is named by the Camel flag .

Array

Arrays should always be named in the following way:

byte[] buffer;

Instead of:

BYTE buffer[];

Method

The first word of the method name must be all lowercase, followed by the first letter of the word capitalized.

Example:toStringCheckvalid

Parameters of the method

The parameters of the method should always be named with the name of the variable and as far as possible using the Camel flag method .

XmlCode

Writing specifications

The code's writing specification is primarily a specification of code from annotations and writing habits. A section of the code is not only easy to debug in time to find the wrong place, more can give others or later own maintenance brings many conveniences, need to pay attention to the following points:

1. Comment Document
2. The passage of
3. Multi-line statement paragraph
4. Use spaces and Blank lines
5. Method cannot be too long, follow the rules of the second
6. Defines the delivery of messages, which are reflected in the comments
7. A short command line
8. Keep the comparison constant on the left to prevent mis-writing as an assignment statement

Comment External Comment

External annotations refer to adding Comment headers to files, classes, methods, and so on, and you can quickly add comments using Eclipse's comment template feature, commenting on template setup methods ,eclipse->windows-> Preferences->java->code Style->code templates->comments is hereby unified as follows:

Files:

/**

* @Title: ${file_name}

* @Package ${package_name}

* @Description: ${todo}

* @author Finger

* @date ${date} ${time}

* @version V1.0

*/

Types:

/**

* @title ${type_name}

* @descript ${todo}

* @authorfinger

* @date ${date} ${time}

* @versionV1.0

*/

Fields:

/**

* @Fields ${field} ${todo}

*/

Constructors:

/**

*<p>title: </p>

*<p>description: </p>

*${tags}

*/

Methods:

/**

* @title ${enclosing_method}

* @descript ${todo}

* @param ${tags}

* @return ${return_type}

* @throws

*/

overriding methods:

/* (non Javadoc)

*<p>title: ${enclosing_method}</p>

*<p>description: </p>

*${tags}

*${see_to_overridden}

*/

Delegate methods:

/**

*${tags}

*${see_to_target}

*/

Getters:

/**

* @return The ${bare_field_name}

*/

Setters:

/**

* @param ${param} The ${bare_field_name} to set

*/

External annotations should be supplemented with the complete following information where necessary

@descript describe the function of member methods and the reasons for their existence

@author name followed by the corresponding author

@version Text Insert version information for the specified text

@param parameter - Name Description

@return return Value Description

@exception the full class name description information

@throws the full class name description information

@see refer to other classes in the following format:@see class name

@see Full class name

@see Full class name # method name

{@link reference }

@Override overloaded functions must add overload markers to the function header

Internal notes

1. The logic of unifying the annotation method inside the beginning of the method
2. Control structure, the starting position of structural statements need to be noted, control structure of the tail
3. Specify local variables
4. Comment Closing brackets }
5. Note to be appropriate, make the code paragraph clear, at a glance.

Writing habit Indentation

Indent general references the indentation of Eclipse default Format , whicheclipse uses ctrl+shift+f shortcut key to quickly format the current file code, the default indentation is 1 a Tab that 4 the character length of a space. The {} of the statement block , where {to follow the end of the block start statement, such as a function definition, anif condition, and a loop statement, theelse statement does not separate another row.

Cases:

if ("ABCD". Equals (SName)) {

......

}else{

......

}

Space

In principle, variables, classes, constant data, and functions are appropriately spaced between their types, decorated names, and aligned according to circumstances. Keyword principle above a lattice, such as:if (...)and so on. The space for the operator is defined as follows:"::"," ,","[","]"," ","--","~","!"," ","-"(means sign),"&"(Reference) a few operators with no spaces on either side (where the monocular operator refers to one side connected to the operand), the other operators (including most two-mesh operators and three-mesh operators"?:"Add a space on both sides, in the function definition can also be as far as the situation is empty or not empty glyd alignment, but the function can not be implemented. ","The operator is only then empty, and it is not empty or multiple spaces when it needs to be aligned. Whether or not there is a parenthesis, apply the appropriate spaces to the statements that are added to the statement line, separating them from the statement and aligning as possible.

Snap To

In principle, a closely related line should be aligned, and the alignment includes parts such as type, adornment, name, parameter, and so on. The length of each line should not exceed the screen too much, if necessary, the appropriate line wrap, as possible at the "," or at the operator at the time of wrapping, it is best to begin with an operator, and the following lines are indented the first line of the statement, but the statement is still in the first line of indentation, such as its next behavior ' {' should be aligned with the first line. Variable definitions are best aligned by adding spaces, and variables of the same type are best placed together. As shown in the following example:
int Value;

int Result;

int Length;

Object Currententry;

Blank Line

There must be no irregular empty lines, such as 10 consecutive blank lines. program file structure between the parts of empty two lines, if not necessary also can only empty line, the function is generally empty two lines between the implementation, because each function also has a function description comment, it is usually only a blank line or not empty, but for no function description of the situation should be at least a blank line.

Code length

For each function it is recommended to control as much as possible the code length of the line, more than a line of code to reconsider splitting it into two or more than two functions. The function splitting rule should be based on the original algorithm without destroying it, while the split part should be reusable. For repetitive code that is used in multiple modules or forms, it is entirely possible to become a function of a common nature and put it in a common module.

Page width

The page width should be set to the zero character. The source code generally does not exceed this width and results in a full display , But this setting can also be flexibly adjusted . in any case ,  Extra-long statements should be wrapped around a comma or an operator .  after a statement has been wrapped ,  should be indented more than the original statement. 2 a character .

Variable initialization

It is best to always define variables to initialize to reduce the generation of bugs that are not easily debugged .

Remove warning

Warnings in the file should be tried or tried to eliminate the warning, for temporarily long unused functions, you can use Add @suppresswarnings ("unused") to remove the warning or in the configuration library (VSS,CVS,SVN ) To temporarily delete the method if a backup is saved.

Other

For comparisons, you should put constants in front of them to avoid mis-writes as assignment statements or to cause unnecessary null pointer errors.

Cases:

while (0 = = flag) {

......

}

if ("ABCD". Equals (SName)) {

......

}

Reduce unnecessary statements and local variable definitions or redundancy

Cases:

Redundancy of the wording:

Boolean bresult = False;

if (a = = b) {

Bresult = true;

}else{

Bresult = false;

}

return bresult;

The correct wording:

return a = = B;

Redundancy of the wording:

if (Bisfile = = Fasle) {

......

}

The correct wording:

if (! Bisfile) {

......

}

Android Code specification (RPM)