Android Coding Standards

Catalog introduction

• 1. Naming
• 1. Why coding standards are needed
• 2. Package naming
• 3. Class and interface naming
• 4. Method naming
• 5. Variable naming
• 6. Member variable naming
• 7. Constant naming
• 8. Exception naming
• 9. layout naming
• 10.id naming
• 11. Resource naming
• 2. Notes
• 1. File Notes
• 2. Class annotations
• 3. Method annotation
• 4. Class member variables and constant annotations
• 5. Other Notes
• 6. XML Comments
• 3. Code style
• 1. Indent
• 2. Blank line
• 3. Line width
• 4. Other problem description
• 4.1 version update
• 4.2 Reference Links
• 4.2 Personal Blog

0. Remarks

• It is recommended to combine code to read blogs more efficiently. Project address: https://github.com/yangchong211/
• A large summary of blogs, continuously updated catalog descriptions, and records of all open source projects and blogs
• If the project is good, you can star it...

1. Naming

1. Why do we need coding conventions?

• Coding conventions are especially important to programmers for several reasons:
  • In the life cycle of a software, 80% of the cost is maintenance
  • Hardly any piece of software is maintained by its original developer throughout its entire life cycle
  • Coding conventions can improve the readability of software and allow programmers to understand new code as quickly and thoroughly as possible
  • If you're releasing source as a product, you need to make sure it's well packaged and unmistakable, just like any other product you've built

2. Package naming

• Naming rules:

  • A unique package name is always prefixed with all lowercase ASCII letters and is a top-level domain name
  • Usually the subsequent part of the com.edu.gov.mil.net.org package name varies according to the internal naming conventions of different institutions
  • Such naming conventions may consist of specific directory names to distinguish departments, projects, machines, or login names.

• For example: com.ycbjie.player

• Convention: The package name must start with com.ycbjie, followed by the project name (or abbreviation), followed by the module name or level name.

  • Such as: com.ycbjie. Project abbreviation. Module name com.ycbjie.player.bookmark
  • Such as: com.ycbjie. Project abbreviation. Hierarchy name com.ycbjie.player.activities

• The meaning of the module package name

  • activity put activity related files
  • service Put Service-related files
  • broadcast broadcast broadcast receiver related files
  • Fragment put fragment related files
  • view put custom view or view file
  • Utils put tool class files
  • bean/entry put entity class file
  • http put request network file
  • api put the file that provides the interface on the server side
  • base put and extract public class files
  • cache puts cached files
  • db put database processing related files
  • inter put interface class file
  • listener
  • adapter Put adapter related files
  • callback

3. Class and interface naming

• Naming rules: The class name is a noun, mixed case, and the first letter of each word is capitalized
• Try to keep your class names as concise and descriptive as possible. Use full words, avoid abbreviations (unless the abbreviation is used more widely, like URL, HTML)
• Interfaces generally use suffixes such as able, ible, er, etc.
• For example: class Raster; class ImageSprite; Convention: The class name must use the camel case rule, that is, the first letter must be capitalized, if it is a phrase, the first letter of each word must also be capitalized, and the class name must use nouns, or noun phrases.
• Such as: class BookMarkAdd is correct
• Such as: class AddBookReadPlanActivity error! Expected class BookReadPlanAdd

4. Method naming

• Naming rules: The method name is a verb in mixed case, the first letter of the first word is lowercase, and the first letter of the following words is uppercase
• 例如： public void run(); public String getBookName();
• Naming of commonly used methods in classes:
  • The acquisition method of a class (generally with a return value) generally requires the addition of get before the name of the field being accessed, such as getFirstName(), getLastName(). In general, the get prefix method returns a single value, and the find prefix method returns a list of values.
  • The setting method of the class (generally the return type is void): add the prefix set before the name of the accessed field, such as setFirstName(), setLastName().
  • The Boolean judgment method of a class generally requires the method name to be prefixed with the word is or has, such as isPersistent(), isString(). Or use words with logical meanings, such as equal or equals.
  • Ordinary methods of the class generally use a complete English description to describe the function of the member method. The first word should use a verb as much as possible, and the first letter is lowercase, such as openFile(), addCount().
  • Constructors should be written incrementally. (The more parameters are written later).
  • toString() method: In general, each class should define toString() in the format:

5. Variable naming

• Naming rules: lowercase the first letter of the first word, capitalize the first letter of the following words

  • Variable names should not start with an underscore or dollar sign, although this is syntactically allowed.
  • Variable names should be short and descriptive. Variable names should be chosen to be easy to remember, that is, to indicate their purpose.
  • Try to avoid single-character variable names unless they are one-time temporary variables. Temporary variables are usually named i, j, k, m and n, which are generally used for integer types; c, d, e, which are generally used for character types.

• Convention: Variable names must also use the camel case rule, but the first letter must be lowercase, and variable names should use nouns or noun phrases as much as possible. Simple and easy to understand, no meaningless words are allowed.

• Such as: String bookYCName; correct

• Such as: String bookYCNameString; Wrong!

6. Member variable naming

• Name the same variable, but don't add the word m before the private variable!

7. Constant naming

• Naming rules: declarations of class constants should be all uppercase, and words should be separated by underscores
• For example: static final int MIN_WIDTH = 4;
• For example: static final int MAX_WIDTH = 999;
• 例如：static final int GET_THE_CPU = 1;

8. Exception naming

• Custom exception names must end with Exception. has been clearly marked as an exception.

9. layout naming

• Specification: The naming of layout xml must be all lowercase words, separated by underscores, and use nouns or noun phrases, that is, use module name_function name to name.
• Such as: knowledge_gained_main.xml is correct
• Such as: list_book.xml error!

10.id naming

• Specification: The id used in the layout must be all lowercase words, separated by underscores, and use nouns or noun phrases. It is required to be able to directly understand the function to be implemented by the current component through the id.
• For example: a TextView @+id/tvbookname  Wrong! It should be @+id/tv_book_name
• For example: An EditText @+id/etbookname  Wrong! It should be @+id/et_book_name

11. Resource naming

• Specification: All resources (such as drawable, style, etc.) used in the layout must be named in lowercase with all words separated by underscores, and use nouns or noun groups as much as possible, that is, use module name_purpose to name. If it is a public resource, such as a dividing line, etc., name it directly with the purpose
• Such as: menu_icon_navigate.png is correct
• For example: a dividing line: line.png or separator.png is correct

2. Notes

• Java programs have two types of annotations:
  • Implementation comments are comments delimited with /.../ and //.
  • Document comments. Documentation comments are delimited by /**...*/. Documentation comments can be converted into HTML files using the javadoc tool.

1. File Notes

• All source files should have a comment at the beginning listing the class name, version information, date, and a copyright notice.

/*
* 文件名
* 包含类名列表
* 版本信息，版本号
* 创建日期。
* 版权声明
*/

2. Class annotations

• Each class should contain comments in the following format to describe the functions of the current class, etc.

/**
 * <pre>
 *     author: yangchong
 *     blog  : www.ycbjie.cn
 *     time  : 2017/01/24
 *     desc  : 图片加载工具类
 *     revise: 修改备注信息
 * </pre>
 */

3. Method annotation

• Each method must contain comments in the following format, including the purpose of the current method, the meaning of the current method parameters, the content of the current method return value and the list of exceptions thrown.

/**
 * 方法的一句话概述
 * <p>方法详述（简单方法可不必详述）</p>
 * @param s 说明参数含义
 * @return 说明返回值含义
 * @throws IOException 说明发生此异常的条件
 * @throws NullPointerException 说明发生此异常的条件
 */

4. Class member variables and constant annotations

• Member variables and constants require comments in the form of java doc to explain the meaning of the current variable or constant /* XXXX meaning / or //XXXx meaning

5. Other Notes

• If the comment inside the method needs to be multi-line, use the form of /*... */
• If it is a single line, it is a comment in the form of //....
• Do not use java doc-style comments "/.../" inside methods

6. XML Comments

• Specification: If the current layout or resource needs to be called in multiple places, or the layout for public use (if list_item), you need to write a comment in xml. Clear and understandable comments are required.

3. Code style

1. Indent

• Specification: Tabs are not allowed for indentation, but spaces are used for indentation. The recommended indentation is 2 spaces.

2. Blank line

• Blank lines separate logically related sections of code to improve readability.
• Blank lines should always be used in the following situations:
  • between two sections of a source file
  • Between class declaration and interface declaration
  • between the two methods
  • Between local variables within a method and the first statement of the method
  • between two logical segments within a method to improve readability
• Convention: Usually, the variable declaration area should be separated by a blank line, the constant declaration area should be separated by a blank line, and the method declaration should be separated by a blank line.

3. Line width

• There is no special regulation, because the current monitors are relatively large, it is recommended to use 120 for the setting.

4. Other problem description

4.1 version update

• v1.0.0 November 19, 2016
• v1.0.1 Jan 17, 2017
• v1.0.2 February 8, 2018

4.2 Reference Links

• The Ali coding specification document can be downloaded directly. It is strongly recommended that programmers take a serious look. really good

4.2 Personal Blog

• github： https://github.com/yangchong211
• Zhihu: https://www.zhihu.com/people/yang-chong-69-24/pins/posts
• Jianshu: http://www.jianshu.com/u/b7b2c6ed9284
• csdn： http://my.csdn.net/m0_37700275
• Himalayan Listening Book: http://www.ximalaya.com/zhubo/71989305/
• The days on the Internet: http://www.jcodecraeer.com/member/content_list.php?channelid=1
• Email: [email protected]
• Alibaba Cloud Blog: https://yq.aliyun.com/users/article?spm=5176.100239.headeruserinfo.3.dT4bcV