Android Development Code Specification

Android Developing code specifications

1. Naming principles
In object-oriented programming, it is very tricky to name classes, objects, methods, variables, and so on. For example, case sensitivity, using different letters to start, and so on. However, the pursuit of its source, in the name of a resource, should be based on the description and uniqueness of the two characteristics to name, in order to ensure that there is no conflict between the resources, and each one is easy to remember.

For understanding the logical flow of applications, naming schemes are the most influential kind of help. The name should describe "what" rather than "how". The naming principle is: Make the name long enough for a certain meaning, and short enough to avoid lengthy. The unique name is programmed only to separate the areas. The following points are the canonical naming methods.

2. Naming the basic specification

2.1. Programming basic Naming conventions
(1) Avoid hard-to-understand names such as attribute name xxK8, which can cause ambiguity.
(2) In an object-oriented language, it is superfluous to include the class name in the name of the class attribute, such as book.booktitle, but should use Book.title.
(3) in languages where function overloading is allowed, all overloads should perform similar functions.

(4) Use a verb-noun method to name a routine that performs a specific action on a given object, such as Calculateinvoicetotal (). (a routine is a collection of functionality interfaces or services provided externally by a system)

(5) If appropriate, add the qualifier (AVG, Sum, Min, Max, Index) at the end or beginning 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 values, such as Fileisfound.

(8) Use meaningful names even for variables that may appear to be short-lived in only a few lines of code. Use single-letter variable names for short-loop indexes only, such as I or J.

(9) To help differentiate variables and routines, use Pascal casing (calculateinvoicetotal) for the routine name, where the first letter of each word is capitalized. For variable names, use camel casing (documentformattype), where the first letter of each word is capitalized except for the first word.

(10) Instead of using literal numbers or literal strings, use named constants, Num_days_in_week, for maintenance and understanding.

2.2. Classification naming conventions

(1) Name of package

The Java package name is made up of lowercase words. However, due to the Java object-oriented programming feature, each Java programmer can write their own Java package, in order to guarantee the uniqueness of each Java package naming, in the latest Java programming specification, the programmer is required to add a unique prefix to the name of the package they define. Because domain names on the Internet are not duplicated, programmers generally use their own domain name on the Internet as the only prefix for their packages.

Example: Net.frontfree.javagroup

(2) Naming of classes

The name of the class must start with a capital letter and the other letters in the word are lowercase, and if the class name consists of multiple words, the first letter of each word should be capitalized such as Testpage, and if the class name contains a word abbreviation, each letter of the word should be capitalized, such as: Xmlexample, One more naming technique is that because a class is designed to represent an object, you should choose a noun when you name the class.

For example: Circle

(3) Naming of methods

The first word of the name of the method should begin with a lowercase letter, and the following words begin with a capital letter.

Example: Sendmessge

(4). Name of the constant

The names of the constants should all use uppercase letters and indicate the full meaning of the constant. If a constant name consists of multiple words, you should use underscores to split the words.

Example: Max_value

(5) Naming of parameters

The naming conventions for parameters are the same as the naming conventions for methods, and to avoid confusion when reading a program, make the name of the parameter as clear as possible if the parameter name is a single word.

(6) Javadoc notes

In addition to the common annotations that Java can use, the Java language Specification defines a special kind of comment, which is what we call the Javadoc annotation, which is used to record the API in our code. Javadoc comments are a multiline comment that begins with/** and ends with a comment that can contain some HTML tags and specific keywords. The advantage of using the Javadoc annotation is that comments written can be automatically converted to online documents, eliminating the hassle of writing program documents separately.

For example:

/**

* This is an example of

* Javadoc

*

* @author Darchon

* @version 0.1, 10/11/2002

*/

At the beginning of each program, generally use Javadoc annotation to the overall description of the program and copyright information, and then in the main program for each class, interface, method, field to add Javadoc comments, the beginning of each note in a sentence to summarize the class, interface, methods, fields completed functions, This sentence should occupy a single line to highlight its general role, in the following sentence can follow a more detailed description of the paragraph. After a descriptive paragraph, you can also follow some special paragraphs that start with the Javadoc comment tag, such as the @auther and @version in the example above, which appear in the generated document in a specific way.

Although adding comments to a poorly designed program does not make it a good program, writing programs according to programming specifications and adding good annotations to your programs can help you write programs that are perfectly designed, run efficiently, and are easy to understand, especially if the programming specification becomes more important when multiple people work together to complete the same project. As the saying goes, "Ax", it's good to spend a little time adapting to the Java programming specification.

3. Classification naming conventions

3.1. Basic data type naming specification

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

such as: String Srtname;

3.2. Naming conventions for controls

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:spn_+ 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

The control description is as follows:

TextView-Text display controls

button-button controls

ImageButton-Picture Button control

ImageView-Picture display controls

checkbox-check box control

RadioButton-Radio box control

AnalogClock-Clocks (the kind with the dial) controls

DigitalClock-Electronic Watch controls

DatePicker-Date selection control

Timepicker-Time selection control

ToggleButton-Double-state button control

EditText-Editable text controls

ProgressBar-progress bar control

Seekbar-draggable progress bar control

Autocompletetextview-Editable text control with auto-completion enabled

Multiautocompletetextview-Editable text control that supports AutoComplete, allowing multiple values to be entered (multiple values are automatically separated by the specified delimiter)

zoomcontrols-Zoom In/Out button control

include-integrated controls

Videoview-Video playback controls

WebView-Browser Controls

Ratingbar-scoring controls

tab-Tab control

spinner-drop-down box control

chronometer-Timer control

ScrollView-scroll bar control

Textswitcher-Text converter control (adds some animation effects when changing text)

gallery– Gallery Controls

Imageswitcher-Picture Converter controls (add some animations when changing pictures)

GridView-Grid control

ListView-List control

expandablelist-List control that supports the expand/Shrink feature

3.3. Variable Naming conventions

Variable naming: Prefix + type description + meaning description

Prefix:

Member variable: m_*** local variable: l_*** parameter: a_***

Constant: Uppercase _*** enumeration value: em_***

3.4. Procedure Specification

The name of the project is: description

The name of the application is named: Description +app

4. Code Writing Specification
(1) Establish a standard indent size (such as four spaces) and consistently use this standard. Aligns the code section with the specified indentation.

(2) Use a specific font and font size (new Arial, small fifth) when publishing the hard copy version of the source code.
(3) Align the left and right brackets vertically in the position of the brackets aligned, such as:
for (i=0; i<100; i++)
{
;
}
(4) Indenting code along logical structure lines makes the code easier to read and understand, such as:
if (expression)
{
if (expression)
{
//
Fill in your code block here;
//
}
Else
{
//
Fill in your code block here;
//
}
}
(5) Establish the maximum line length for comments and code to avoid having to scroll the source editor and provide a neat hard-copy representation.
(6) When a line is too long and must be wrapped, use the indent format in the following line-wrapping code, as follows:
String inserstring = "Insert into TableName (username,password,email,sex,address)"
+ "Values (' soholife ', ' chenyp ', ' [email protected] ', ' Male ', ' Shenzhen Futian ')";
(7) The statement placed on each line avoids more than one line. Special loops, such as for (I =0;i<100;i++), are excluded.
(8) When writing an SQL statement, use all uppercase for the keyword and use case blending for database elements such as tables, columns, and views. For example select * from Table1;
(9) Placing each major SQL clause on a different line makes it easier to read and edit statements, such as:

SELECT FirstName, LastName
From Customers
WHERE state = ' WA '

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

(11) Use whitespace to provide structural clues to the source code. Doing so creates a code "segment" that helps the reader understand the logical segmentation of the software
(12) Divide large complex code segments into smaller, easier-to-understand modules.

5. Notes
Software documentation exists in two forms: external and internal. External documents, such as specifications, help files, and design documents, are maintained outside the source code. Internal documentation consists of comments that developers write in the source code at development time.
Regardless of the availability of external documents, the source code list should be able to exist independently because hard-copy documents may be misplaced.   External documents should consist of specifications, design documents, change requests, error histories, and coding standards used. The following points are the annotated methods of the specification:

(1) A project should have a unified header file annotation to illustrate the entire project information, creation date, version, etc.

(2) Explanation of important procedures and annotations

(3) When the code is modified or deleted, the original code is masked by the method of annotation, and the developer's own comments on the modification operation are added. The format is:

Original code

Added/(modified/deleted) by developer name year-month-day;

For business reasons, please indicate the reason for modification or deletion)

New Code
(4) Use the XML document format, such as the following method of comments:
<summary>
Get SB. 's Age
</summary>
<param name= "UserName" > Username </param>
<returns> User Age </returns>
public int Getuserage (string userName)
{
//
Write your program code here
//
}

(5) Avoid messy annotations, but instead use whitespace to separate comments from the code.
(6) Remove all temporary or extraneous comments to avoid confusion in future maintenance work.
(7) Comments should be accurate description of the code, there should be no ambiguity.
(8) Constructs annotations throughout the application using a uniform style with consistent punctuation and structure.

Android Development Code Specification (RPM)