Android development specifications that are worth your learning (top)

• Objective

• As specification

• Naming conventions

• Resource file specification

• Unified Version Specification

• Third-party library specifications

• Annotation specification

• Some of the other specifications

1

Objective

In order to facilitate the project maintenance and standardize the development, promote the efficiency of code review among members, so put forward the following development specifications, if there are better suggestions, welcome to GitHub to mention issue.

Github:https://github.com/blankj/androidstandarddevelop

2

As specification

工欲善其事, its prerequisite.

1. Try to use the latest version of the IDE for development;

2. The encoding format is unified for UTF-8;

3. After editing. Java,. XML and other files must be formatted (the basic format is used as the default template);

4. Remove excess import, reduce warnings, and use the As Optimize imports (Settings→keymap→optimize imports) shortcut key;

5. As common development plug-in can refer to here ~ "as common development plug-in" (Https://github.com/Blankj/AndroidStandardDevelop)

3

Naming conventions

The naming in the code is strictly forbidden to use Pinyin in combination with English, and it is not allowed to use Chinese in a direct manner. Correct English spelling and grammar can make readers easy to understand and avoid ambiguity.

Note: Even pinyin naming methods should be avoided. But Alibaba, Taobao, Youku, Hangzhou and other international common name, the visual same as in English.

3.1 Package Name

Package name all lowercase, consecutive words are simply connected, do not use underscores, use the anti-domain naming rules, all use lowercase letters. The first level of the package name is the top-level domain name, usually com,edu,gov,net,org, two-level package name for the company name, three-level package name according to the application of the name, followed by the division of the package name, on the division of the package name, the recommended use by function, at the beginning we also according to the layer to subcontract, very pit dad Depending on the function, you may not be very good at distinguishing between the functions, but also more than you can distinguish between layers to find a lot. Specific can refer to this blog post ~package by features, not layers, of course, our big Google also has the corresponding sample~iosched, its structure as shown below, it is worth learning.

Refer to the code structure for Google I/O 2015, which can be done by functional subcontracting:

The advantages of PBF (according to the functional subcontracting package by Feature) and PBL (by layer) are as follows:

1.package internal high cohesion, low coupling between package

Which one to add new features, only to change a package under the things.

Class functional Layering (PBL) reduces code coupling, but brings the package coupling, to add new features, need to change model, dbhelper, view, service and so on, need to change the code under several package, change the more places, It's easier to create new problems, isn't it?

According to the function sub-package (PBF), Featurea related all things are in the Featurea package, feature high cohesion height of the modular, different feature between the low coupling, related things are put together, but also easy to find.

2.package has a private scope (package-private scope)

You are responsible for developing this feature, and everything in this directory is yours.

The way of PBL is to put all the tools in the Util package, Xiao Zhang development of new functions when it is necessary to find a xxutil, but it is not universal, that should be put where? No way, according to the principle of layering, we have to put under the Util package, it seems inappropriate, but placed in other packages more inappropriate, more and more functions, util class is more defined. Later, Xiao Li was responsible for the development of a function found to need a xxutil, the same is not general, to util package A look, how has been, but also can not reuse, had to give up XX this name, changed to Xxxutil ... Because the PBL package does not have a private scope, each packet is public (cross-package method invocation is a common thing, each package is accessible to other packages)

If it is PBF, Xiao Zhang's xxutil naturally placed under Feautrea, Xiao Li's xxutil in Featureb, if the util seems to be universal, go to util package to see if you want to add tool method Xxutil,class naming conflict No

PBF package has a private scope, Featurea should not access anything under FEATUREB (if not accessible, it indicates a problem with the interface definition)

3. Easy to Remove Features

Statistics found no use of new features, this version of the block function to be removed.

In the case of PBL, you have to remove all the code and classes that have been implicated from the function entry to the entire business process and delete it, and you'll end up accidentally.

If it is PBF, say, first delete the corresponding package, and then delete the function entrance (delete the entrance must be wrong), finished.

4. Highly abstract

The general way to solve the problem is from abstraction to concrete, the PBF package name is the abstraction of the function module, the class in the package is the implementation details, conforms to from the abstraction to the concrete, and the PBL is reversed.

PBF starting from the determination of appname, according to the Functional module division package, and then consider the specific implementation details of each block, and PBL from the outset to consider the DAO layer, not the COM layer and so on.

5. Separate logic code by class only

PBL separates the class from the package, and PBF only separates the logic code by class.

There is no need to detach from the package because there may be awkward situations in PBL:

According to all things under the Pbl,service package is controller, should not need serv suffix, but in fact usually for the convenience of code, direct import service package, serv suffix is to avoid the introduction of class and the current package class naming conflicts , of course, without a suffix, you have to write clearly the packet path, such as New Net.ayqy.service.Main (), Trouble.

And PBF is very convenient, no import, direct new Mainserv () can be.

The size of the 6.package is meaningful.

The unlimited increase in the size of the package in PBL is reasonable, because the more functions are added.

The PBF package is too large (too many in the package) to indicate that this chunk needs to be refactored (sub-packages).

3.2 Class Name

Class names are written in uppercamelcase style.

The class name is usually a noun or noun phrase, and the interface name can sometimes be an adjective or an adjective phrase. There are no specific rules or valid conventions for naming annotation types.

Nouns, using the big hump nomenclature, try to avoid abbreviations, unless the abbreviation is well known, such as HTML, URL, and if the class name contains a word abbreviation, each letter of the acronym should be capitalized.

The test class is named to start with the name of the class it is testing, ending with test. For example: Hashtest or Hashintegrationtest.

Interface (interface): Naming rules, like classes, use the large hump nomenclature, which ends with able or ible, as
Interface Runnable, interface Accessible.

Note: If the project uses MVP, all the model, View, and presenter interfaces are prefixed with I, without suffixes, and the other interfaces use the above naming conventions.

3.3 Method Name

Method names are written in lowercamelcase style.

The method name is usually a verb or a verb phrase.

3.4 Constant Name

The constant name mode is constant_case, all letters are capitalized, and the words are separated by underscores. So, what exactly is a constant?

Each constant is a static final field, but not all static final fields are constants. When deciding whether a field is a constant, consider whether it really feels like a constant. For example, if any one of the observed states of the instance is mutable, it will almost certainly not be a constant. Just never plan to change the object is generally not enough, it must be really unchanged in order to show it as a constant.

3.5 Number of field names

The field name of the lowercamelcase is transformed into the following style based on the style: The basic structure is scopevariablenametype.

Scope: Range

Non-public, non-static field names begin with M.

The static field name begins with S.

Public non-static field names begin with P.

public static fields (global variables) are named starting with G.

Example:

Using a 1-character prefix to represent the scope, the 1-character prefix must be lowercase, followed by a ideographic word or multiple word names, and the first letter of each word capitalized, the other letters lowercase, so that the variable name can be correctly segmented.

Type: Types

Given that many UI controls are used in Android, all the member variables used to represent the control are uniformly combined with the control abbreviation as the suffix (appended with the abbreviation table) to avoid confusion and better expression of the control and ordinary member variables.

For ordinary variables generally do not add a type suffix, if you add the type suffix uniformly, please refer to the abbreviation table at the end of the article.

By placing a quantifier at the end of a uniform quantifier, you can create more uniform variables that are easier to understand and easier to search.

Note: If you use Butterknife in your project, you do not add the M prefix, which is named Lowercamelcase style.

For example, use Mcustomerstrfirst and mcustomerstrlast instead of using MFIRSTCUSTOMERSTR and MLASTCUSTOMERSTR.

Description

The collection adds the following suffix: List, Map, Set
Add the following suffix to the array: ARR

Note: All VO (Value objects) are written uniformly in the standard lowercamelcase style, and all DTOs (data transfer objects) are written according to the field names defined in the interface documentation.

3.6 Name of the parameter

The name of the parameter is written in lowercamelcase style.

Parameters should avoid naming with a single character.

3.7 Local variable name

Local variable names are written in lowercamelcase style, and local variable names can have looser abbreviations than other types of names.

Although the abbreviations are looser, you should avoid naming them with single characters, except for temporary and cyclic variables.

Even if the local variable is final and immutable, it should not be shown as a constant, nor can it be named with constant rules.

3.8 Temporary variables

Temporary variables are usually named I, J, K, M, and N, which are generally used for integer types, and C, D, E, which are generally used for character types. For example: for (int i = 0; i < len; i++).

3.9 Type variable Name

Type variables can be named in one of the following two styles:

• A single uppercase letter, followed by a number (such as: E, T, X, T2).

• Named by Class (refer to the 3.2 class name), followed by an uppercase T (for example: Requestt, Foobart).

Android development specifications that are worth your learning (top)