Coding standards, Git branch organization

Code naming convention

Package naming convention

Adopt anti-domain name naming rules and use all lowercase letters. The first-level package name is com, the second-level package name is kl (it is the company name, which can be abbreviated), the third-level package name is pos (named according to the application), the fourth-level package name is activity or adapter, etc. (module name or level name), according to In actual situations, you can also use five-level package names and six-level package names. For example: com.kl.pos.activity | com.kl.pos.adapter

Special project naming convention

You can add a fixed project prefix based on the existing specifications, such as kl project, the Activity can be changed to KlLoginActivity, and the Layout can be kl_activity_login. In order to prevent this special project from being referenced, there are many files with the same name when searching for files, and the modification and maintenance costs are high.

Class file naming method

Activity naming always uses the module name + Activity. For example: LoginActivity, UserActivity.
Fragment naming always uses the module name + Fragment. For example: HomeFragment, WeatherFragment.
Customize View function name + View/ViewGroup (specific component name). For example: WhiteLayout, RatingView.
Widget component function name + Widget. For example: ScanWidget, WeatherWidget.
Dialog dialog box function name +Dialog. For example: LoginDialog, ProgressDialog.
Adapter naming always uses the module name + Fragment. For example: HomeAdapter, WeatherAdapter.

Layout naming

Activity activity_module name. For example, R.layout.activity_login
Fragment fragment_module name. For example, R.layout.fragment_login_layout_header
Include layout_module name_function name. For example, @layout/layout_login_bottom
Adapter item_module name_function name. For example, R.layout.item_simple_text
Dialog dialog_module_function name. For example R.layout.dialog_time_picker

Values ​​resource file naming

color color_module name. For example color_material_design
dimens dimens_module name. For example dimens_material_design
style style_module name. For example style_material_design
themes themes_module name. For example themes_material_design
strings strings_module name. For example strings_meatrial_design other modules and so on

Interface naming convention

The naming rules are the same as those of classes, using the big camel case naming method, which usually starts with a capital I (interface abbreviation) or ends with able or ible, such as interface Runnable; interface Accessible. Or refer to a similar Android interface. Such as click event OnClickListener, etc.

Variable naming

Member variables use the camel case naming method userName deviceName.

Constant naming

Letters are in all capital letters and words are separated by underscores _. Regarding the naming method of constants, in JAVA code, it is advocated to use constants to replace numbers and fixed strings at any time. In other words, except for 0 and 1, other numbers should not appear in the program. If 0 and 1 can be replaced, they are not allowed to appear. Constants can be defined at the beginning of the program or in a wider scope. The names should be in uppercase letters and indicate the full meaning of the constant. If a constant name consists of multiple words, the words should be separated by underscore "_" such as: NUM_DAYS_IN_WEEK, MAX_VALUE.

 

Branch naming rules

1. Branch prefix-version number-function

2. The branch prefix is ​​required, the master and develop branches do not need to carry version numbers, and the main release branch does not need to carry functional information.

Branch prefix rules

branch	describe	Is it a protected branch?
master	master branch	yes
develop	main development branch	yes
release	release branch	yes
feature	feature branch	no
hotfix	bug modification branch	no
chore	Add build, automation, and scripted configuration branches	no

Branch relationship flow chart

Branch operation process

new function

1. Cut from the develop branch and name it feature-version number-function

2. KL project code submission must carry the task number or bug number

3. After the function is developed, it is handed over to testers for testing

4. Test the merge into the develop branch and check to delete the original branch.

Functional bug fixes

1. Cut from the develop branch and name it hotfix-version number-function

2. KL project code submission must carry the task number or bug number

3. The bug fix is ​​completed and handed over to testers for testing

4. Test the merge into the develop branch and check to delete the original branch.

Version release branch preparation

1. Cut from the develop branch and name it release-version number-function
   alpha version: name it release-version number-alpha For example: release/2.2.0-alpha
   beta version: name it release-version number-beta For example: release/2.2 .0-beta
   officially launched version: named release-version number, for example: release/2.2.0

2. After modifying the basic steps such as version number and server cut-off, submit the code and attach the task number.

3. Before releasing the version, merge it into the master branch and tag it

4. Follow the version release process

Branch deletion rules

1. Branches merged into develop must be deleted promptly.

2. The main release branch cannot be deleted

3. If the current branch is to be postponed until the specified version goes online, the branch version number must be modified in time, and expired versions must be cleaned up in a timely manner.