Android development code specification

Android development code specification

1. Basic naming principles
In object-oriented programming, naming of classes, objects, methods, and variables is very skillful. For example, case sensitivity, starting with different letters, and so on. However, in order to ensure that there is no conflict between resources, and every one is easy to remember.

The naming scheme is the most influential help for understanding the logical flow of an application. The name should indicate "what" rather than "how ". The naming principle is: make the name long enough for a certain purpose, and be short enough to avoid lengthy. The unique name is only used to differentiate items. The following are standard naming methods.

2. Basic naming rules

2. 1. Basic Programming naming rules
(1) Avoid obscure names, such as the property name xxK8, which may lead to ambiguity.
(2) In an object-oriented language, it is unnecessary to include a class name in the class attribute name, such as Book. BookTitle. Instead, Book. Title should be used.
(3) in languages that allow function overloading, all overloading should execute similar functions.

(4) use the verb-Noun method to name the routine for performing specific operations on a given object, such as CalculateInvoiceTotal (). (A routine is a set of functional interfaces or services provided by a system)

(5) If appropriate, add the computing qualifier (Avg, Sum, Min, Max, Index) at the end or start of the variable name ).
(6) use complementary pairs in variable names, such as min/max, begin/end, and open/close.

(7) The Boolean variable name should contain Is, which means Yes/No or True/False, such as fileIsFound.

(8) even for variables that may only have a short lifetime in several lines of code, they still use meaningful names. Only use single-letter variable names for short-cycle indexes, such as I or j.

(9) to help distinguish between variables and routines, use CalculateInvoiceTotal for the routine name. the first letter of each word is capitalized. For variable names, use camel case-sensitive (documentFormatType). The first letter of each word except the first word is capitalized.

(10) do not use the original numeric or string, but use the name constant NUM_DAYS_IN_WEEK for maintenance and understanding.

2. Classification naming rules

(1) package name

The Java package name is composed of lowercase words. However, due to the characteristics of Java object-oriented programming, every Java programmer can write their own Java packages. To ensure the uniqueness of each Java package name, in the latest Java programming specification, the programmer is required to add a unique prefix before the name of the defined package. Because domain names on the Internet are not repeated, programmers generally use their own domain names on the Internet as the unique prefix of their packages.

Example: net. frontfree. javagroup

(2) Class naming

The class name must start with an upper-case letter and the other letters in the word must be lower-case. If the class name is composed of multiple words, the first letter of each word should be in the upper-case format, such as TestPage; if the class name contains the abbreviation, each letter of the abbreviation should be capitalized, for example, XMLExample. Another naming technique is that the class is designed to represent objects, therefore, you should select a noun whenever possible when naming a category.

Example: Circle

(3) method naming

The first word of the method name should start with a lower-case letter, and the subsequent words should start with an upper-case letter.

Example: sendMessge

(4). Constant naming

The constant names should all use uppercase letters and indicate the complete meaning of the constant. If a constant name is composed of multiple words, the words should be separated by underscores.

Example: MAX_VALUE

(5) parameter naming

The parameter naming rules are the same as the method naming rules. To avoid confusion during reading the program, make sure that the parameter name is a word as clear as possible.

(6) Javadoc comments

In addition to using our common annotation methods, the Java language specification also defines a special annotation, that is, the Javadoc annotation we call, it is used to record APIs in our code. Javadoc comments are multiline comments that start with/** and end with */. Comments can contain HTML tags and specialized keywords. The advantage of using Javadoc annotations is that the compiled notes can be automatically converted into online documents, saving the trouble of writing program documents separately.

For example:

/**

* This is an example

* Javadoc

*

* @ Author darchon

* @ Version 0.1, 10/11/2002

*/

At the beginning of each program, Javadoc is generally used to comment on the overall description of the program and copyright information. Then, Javadoc comments can be added to each class, interface, method, and field in the main program, the first part of each comment first summarizes the functions completed by the class, interface, method, and field in one sentence. This sentence should take a separate line to highlight its generalization, A more detailed description section can be followed after this sentence. After descriptive paragraphs, you can also follow special paragraphs starting with the Javadoc annotation label, such as @ auther and @ version in the preceding example. These paragraphs are displayed in a specific way in the generated document.

Although adding comments to a poorly designed program won't make it a good program, writing programs according to programming specifications and adding good comments to the program can help you write out the perfect design, it is more important to run highly efficient and easy-to-understand programs, especially when multiple people work together to complete the same project. As the saying goes, it is good to spend a little time adapting to Java programming specifications.

3. Classification naming rules

. Basic data type naming rules

Integer: int + description Char: chr + description Boolean: bln + description

Long: lng + description Short: shr + description Double: dbl + description

String: str + description Float: flt + description Single: sng + description

DataTime: dt + description Array: arr + description Object: obj + description

For example, String srtName;

. Control naming rules

TextView: txt _ + description	Button: btn _ + description
ImageButton: imgBtn _ + description	ImageView: imgView _ + description
CheckBox: chk _ + description	RadioButton: rdoBtn _ + description
AnalogClock: anaClk _ + description	DigitalClock: DgtClk _ + description
DatePicker: dtPk _ + description	TimePicker: tmPk _ + description
ToggleButton: tglBtn _ + description	EditText: edtTxt _ + description
ProgressBar: lcb _ + description	SeekBar: skBar _ + description
AutoCompleteTextView: autoTxt _ + description	MultiAutoCompleteTextView: mlAutoTxt _ + description
ZoomControls: zmCtrl _ + description	Include: ind _ + description
VideoView: vdoVi _ + description	WebView: webVi _ + description
RatingBar: ratBar _ + description	Tab: tab _ + description
Spinner: SPNs _ + description	Chronometer: Cmt _ + description
ScrollView: sclVi _ + description	TextSwitcher: txtSwt _ + description
Gallery: gal _ + description	ImageSwitcher: imgSwt _ + description
GridView: gV _ + description	ListView: lVi _ + description
ExpandableList: epdLt _ + description	MapView: mapVi _ + description

Controls are described as follows:

? TextView-text display control

? Button-Button control

? ImageButton-image button control

? ImageView-Image Display Control

? CheckBox-check box Control

? RadioButton-single-Stick Control

? AnalogClock-clock (with table disk) Control

? DigitalClock-workbook Control

? DatePicker-date Selection Control

? TimePicker-Time Selection Control

? ToggleButton-double-state button control

? EditText-editable text Control

? ProgressBar-progress bar Control

? SeekBar-drag progress bar Control

? AutoCompleteTextView-editable text controls that support Automatic completion

? MultiAutoCompleteTextView-editable text controls that support Automatic completion and allow multi-value input (values are automatically separated by specified delimiters)

? ZoomControls-zoom in/out button control

? Include-integrated controls

? VideoView-video playback control

? WebView-browser controls

? RatingBar-scoring Control

? Tab-Tab Control

? Spinner-drop-down box Control

? Chronometer-timer control

? ScrollView-scroll bar Control

? TextSwitcher-Text Converter Control (add some animation effects when changing text)

? Gallery-Gallery controls

? ImageSwitcher-Image Converter Control (some animation effects are added when the image is changed)

? GridView-Grid Control

? ListView-List Control

? ExpandableList-List controls supporting the expand/contract function

3. variable naming rules

Variable name: prefix + type description + meaning description

Prefix:

Member variable: m _ *** local variable: l _ *** form parameter: _***

Constant: uppercase _ **** enumeration value: em _***

. Procedural specifications

Project name: Description

Application name: Description + App

4. code writing specifications
(1) create a standard indent size (such as four spaces) and use this standard in a consistent manner. Align the code section with the specified indentation.

(2) Use a specific font and font size when releasing a hard copy version of the source code (New ,, ).
(3) vertical alignment between the left and right brackets in the bracket-to-alignment positions, for example:
For (I = 0; I <100; I ++)
{
;
}
(4) indent the code along the logical structure line to make the code easier to read and understand, such:
If (expression)
{
If (expression)
{
//
// Enter your code block here;
//
}
Else
{
//
// Enter your code block here;
//
}
}
(5) Create the maximum line length for comments and codes to avoid having to scroll the source code editor and provide neat hard copy representation.
(6) When a line of content is too long and must be changed, use the indent format in the line feed code, as shown below:
String inserString = "Insert Into TableName (username, password, email, sex, address )"
+ "Values ('soholife', 'chenyp', 'soholife @ sina.com ', 'male', 'shenzhen Futian ')";
(7) avoid placing more than one statement on each row. Except for special loops such as for (I = 0; I <100; I ++.
(8) When writing an SQL statement, use uppercase letters for all keywords, and use a mix of uppercase and lowercase letters for database elements (such as tables, columns, and views. For example, SELECT * FROM Table1;
(9) place each major SQL clause on different rows to facilitate reading and editing statements. For example:

SELECT FirstName, LastName
FROM MERs
WHERE State = 'wa'

(10) Logically divide the source code between physical files.

(11) Use a blank space to provide a structure clue for the source code. This will create code segments to help readers understand the logical segments of the software.
(12) divide large and complex code segments into small and easy-to-understand modules.

5. Notes
Software Documents exist in two forms: external and internal. External documents (such as specifications, help files, and design documents) are maintained outside the source code. Internal documents are composed of comments written by developers in the source code during development.
The availability of external documents is not considered. The source code list should be independent because the hard copy document may be put in the wrong place. External documents should consist of specifications, design documents, change requests, error history records, and encoding standards used. The following are standard comments:

(1) A project should have a uniform header file comment to describe the information, creation date, version, and so on of the entire project.

(2) Add notes to important programs

(3) When modifying or deleting the code, block the original code with comments, and add the developer's own comments on the modification operation. Format:

// Original code

// Added/(Modified/Deleted) by developer name year-month-day;

// For business reasons, you must specify the reasons for modification or deletion)

New Code
(4) use the XML document format, as described in the following method:
///

/// Get someone's age
///
/// User Name
/// User age
Public int GetUserAge (string userName)
{
//
// Write your program code here
//
}

(5) Avoid messy comments. Instead, use blank spaces to separate comments from the code.
(6) Remove all temporary or irrelevant comments to avoid confusion during future maintenance work.
(7) annotations should be accurate descriptions of codes, and there should be no ambiguity.
(8) construct comments using a unified style with consistent punctuation and structure throughout the application.