Android Code Specification
Android Coding Standard (Ver 0.1)
0 Universal Principles
1. Straightforward code makes more sense than comments
2. Specifications related to spaces and line breaks need to be imported into eclipse_code_formatter.xml, and the formatting operation will be performed after editing the code.
3. Coders cannot sacrifice the robustness and understandability of the code for the convenience of the diagram
4. The newly added code must fully comply with the specification; if the old code does not comply with the specification, it will be modified synchronously when relevant functions are available.
1 Naming
1.1 The naming needs to be meaningful, try to achieve the level of knowing the name , and avoid meaningless naming.
1.2 The level of detail of variable names depends on the scope of the variable. Member variables > local variables of large functions > local variables of small functions. The larger the scope, the more detailed the variable name should be.
For example, for a type of variable, the member variable is named mCachedShareConfigEvent, and the local variable of the small function can be named event.
1.3 Class name
Use big camel case and try to avoid abbreviations. Common types such as Activity, Fragment, and Adapter should add the corresponding suffix identifier.
Class names are usually nouns or noun phrases, and interface names may sometimes be adjectives or adjective phrases.
1.4 Method name
- In camel case, method names are usually verbs or verb phrases . Boolean type functions are prefixed with a predicate verb.
如initXX()、displayXX()、isXX()。
- Callback class method, add On prefix, such as onRequestFaild(MobileErrorCodemobileErrorCode)
1.5 Variable names
- Use little camel case, and member variables start with m . The constant name naming pattern is CONSTANT_CASE.
- After the prefix, a name consisting of one or more words with strong ideographical meaning.
- Finally, you can add type and quantifier suffixes according to the situation.
Exceptions: CEvent messages and related entity classes; control variables annotated with @ViewById;
ps: Because of the naming restrictions of controls in xml and the view injection of the framework. Control class variable names are lowercase words, separated by underscores, and prefixed with control type abbreviations (see the end of the document for the control abbreviation table).
例：mFollowingAnchorInfos，lv_following_anchors。
1.6 Resource file naming: Because the resource type needs to be referenced by the R file in the code, the general rule is: type prefix + logical description, which is easy to find.
| Types of |
Example |
illustrate |
| contentView |
fragment_room |
Fragment's contentView must correspond to its class name, Convert all letters to lowercase, swap types and functions (that is, suffix to prefix) |
| list item |
item_following_anchors.xml |
item_description.xml |
| id naming |
lv_following_anchors btn_rotate_screen |
view abbreviation _view logical name |
2 Notes
2.1 Each public class, and each of its public member variables and methods need to add Javadoc comments .
The javadoc comment of the function needs to describe the parameters and return value.
Exceptions: Self-explanatory methods such as getter, setter methods. overloaded method.
2.2 Other places where comments need to be added (no need to use javadoc form)
Important private functions and variables; difficult to understand places; special business logic and conventions;
ps: Comments are mainly to explain the meaning of variable names and method names that cannot be explained, do not translate directly. If the naming is good enough, you can leave out the comment.
3 Code quantity limit
3.1 A function body should not exceed 80 lines (unless there is a good reason)
3.2 The braces in the function should not exceed 4 layers
3.3 More than three lines (including three lines) repeated three times (including three times) or more, or more than five lines (including five lines) repeated twice (including two times) or more, the code must write a function ; Consider using parameters to generalize and make it a common piece of code
4 other
3.1 Avoid magic numbers , such as if(res.result==99)
3.2 For xml layout, if the overall layout-child View has spacing requirements, unify the parent layout to make a unified upper, lower, left, and right spacing, and do not do the upper, lower, left, and right spacing of the overall layout for each child control.
99. Appendices
-Variable naming rules
Maintain a dictionary of correspondence between development words and Chinese (after the plan is announced, the function leader will update it), and record relevant default English words and English words for specific tasks. To facilitate the uniformity of naming in development.
For variables that are difficult to name, it is necessary to discuss with everyone, update the word dictionary for development after forming a specific name, and record it in the solution.
- Control abbreviation
| controls |
abbreviation |
example |
| LinearLayout |
ll |
ll_friend 或 mFriendLL |
| RelativeLayout |
rl |
rl_message 或 mMessageRL |
| FrameLayout |
fl |
fl_cart or mCartFL |
| Button |
btn |
btn_home or mHomeBtn |
| TextView |
tv |
tv_name 或 mNameTV |
| EditText |
and |
et_name or mNameET |
| ListView |
lv |
lv_cart or mCartLV |
| ImageView |
iv |
iv_head or mHeadIV |
| GridView |
gv |
gv_photo 或 mPhotoGV |
- Examples of bad variable names
| Bad |
|
| private ClickDiminishListView cdlList; |
meaningless |
| private ArrayList<RewardBasicItem> reList; |
meaningless |
| private int m_gift_id = 0; |
wrong format |
|
|
|
|
|
|
|
|
|