- AS Specification
- Try to use the latest stable IDE for development
- After editing .java, .xml and other files, be sure to format, format, format (if the team has a public style package, then follow it, otherwise use the AS default template uniformly)
- Delete redundant imports and reduce warnings, use the Optimize Imports (Settings-> Keymap-> Optimize Imports) shortcut key of Ctrl + Alt + O
- Naming conventions
- The naming in the code is strictly prohibited to use a combination of Pinyin and English, and it is not allowed to directly use Chinese. Correct English spelling and grammar can make the reader easy to understand and avoid ambiguity
- Note: Even pure Pinyin naming should be avoided. However, international names such as alibaba, taobao, youku, and hangzhou can be regarded as the same in English.
- Code style specifications
- Use the standard brace style {}, the left brace does not occupy a single line, and it is on the same line as the preceding code
- Ordering of function parameters: Context is best as its first parameter
- Name and value of string constants
- static final String PREF_EMAIL = "PREF_EMAIL";
- static final String BUNDLE_AGE = "BUNDLE_AGE";
- static final String ARGUMENT_USER_ID = "ARGUMENT_USER_ID";
- Passing parameters of Activities and Fragments: When the Activity or Fragment needs to pass parameters to start, then it needs to provide a public static function to help start or create it
- Line length limit: The length of each line of text in the code should not exceed 100 characters.
- Resource file specification naming rules: type {_module name} _logical name
- Unified version specification
-
There are many versions of Android development, such as compileSdkVersion, minSdkVersion, targetSdkVersion and the version of the project that depends on third-party libraries. Different modules and different developers have different versions, so a unified version specification file is required.
-
If you are developing multiple system-level applications, when multiple applications use the same so library at the same time, you must ensure that the version of the so library is the same, otherwise it may cause the application to crash
-
- Third-party library specifications
- I hope that Team can use the newer technology nowadays, and the selection of open source libraries generally needs to choose a more stable version. Such as Retrofit, RxAndroid, OkHttp, Glide / Fresco, Gson / Fastjson, EventBus / AndroidEventBus, GreenDao
- Annotation specifications
-
Class comments: After each class is completed, there should be a note of the author's name and contact information, and they are responsible for their own code.
-
Method comment: The method header of each member method (including custom member methods, overriding methods, and attribute methods) must be commented on the method header. Enter / ** + Enter or set Fix doc comment (Settings-> Keymap-> Fix doc comment) shortcut key, AS will help you generate a template, we only need to complete the parameters
-
Block comments: Block comments are at the same indentation level as the code around them. They can be in the style of / * ... * / or in the style of // ... (preferably with a space after //). For multi-line / * ... * / comments, subsequent lines must start with * and be aligned with * on the previous line.
-
Some other comments: AS has integrated some comment templates for you. We only need to use them directly. Enter these comment templates such as todo and fixme in the code, and it will appear after you press Enter.
-
- Interface specification
-
The overall unification of data:
According to the existing data format, it is recommended that the returned data be unified as: {"status": 1, "msg": "success", "data": "" ... "} data is the corresponding returned data, which can be JSON key-value pairs If the data of any type is abnormal, status is 0 or other defined integer, msg is error message, and the corresponding format of data is as follows:
- By LiYing
-