2301-MUSE Front-end Coding Standards

EmoGenius Crew

Which course does this assignment belong to	2301-MUSE Community
Assignment Requirement	Teamwork——Alpha Sprint
Team Name	EmoGenius Crew
The Aim of This Assignment	Sprint Essay
Topical Collection Essay	EmoGenius Crew - Alpha SprintTopical Collection of Essays

1. AS Specification

Good tools are prerequisite to the successful execution of a job.

• Use the 2022.3.1 Patch 1 Giraffe Edition IDE for development.
• Coding format should be UTF-8.
• After editing .java, .xml, and other files, remember to format them.
• Delete unnecessary imports to reduce warnings. It is recommended to use the Optimize Imports shortcut in Android Studio.

2. Naming Conventions

Using a combination of Pinyin and English in code names is strictly prohibited, as is using Chinese directly. Correct English spelling and grammar make it easier for readers to understand and avoid ambiguity.

2.1 Package Names

Package names should be all lowercase. Concatenate consecutive words without using underscores. Use the reverse domain name convention and lowercase letters only.

2.2 Class Names

Class names should be written in UpperCamelCase style.
Class names are usually nouns or noun phrases, while interface names may sometimes be adjectives or adjective phrases.
For nouns, use the UpperCamelCase naming convention and try to avoid abbreviations unless they are widely known, such as HTML or URL. If a class name includes abbreviations, each letter of the abbreviation should be capitalized.

2.3 Method Names

Method names should be written in lowerCamelCase style.
Method names are usually verbs or verb phrases.

2.4 Constant Names

Constants should be named using the CONSTANT_CASE pattern, with all letters in uppercase and words separated by underscores. Each constant should be a static final field, but not all static final fields are constants.

3. Code Style Guidelines

3.1 Use Standard Brace Style

Opening braces should be on the same line as the corresponding code, not on a new line.

class MyClass {
    int func() {
        if (something) {
            // ...
        } else if (somethingElse) {
            // ...
        } else {
            // ...
        }
    }
}

3.2 Order of Class Members

Using a consistent order improves code readability. The following order should be used for this project:

• Constants
• Fields
• Constructors
• Overridden methods and callbacks
• Public methods
• Private methods
• Inner classes or interfaces

public class MainActivity extends Activity {
    private static final String TAG = MainActivity.class.getSimpleName();
    private String mTitle;
    private TextView mTextViewTitle;
    @Override
    public void onCreate() {
    }
    public void setTitle(String title) {
    }
    private void setUpView() {
    }
    static class AnInnerClass {
    }
}

3.3 Ordering of Function Parameters

In Android development, it is common to have Context as the first parameter in function signatures. On the other hand, callback interfaces should be the last parameter.

// Context always goes first
public User loadUser(Context context, int userId);

// Callbacks always go last
public void loadUserAsync(Context context, int userId, UserCallback callback);

3.4 Naming and Values of String Constants

Many classes in the Android SDK use key-value pairs, such as SharedPreferences, Bundle, and Intent. Thus, even for small applications, a large number of string constants need to be defined. When using these classes, the keys must be defined as static final fields and follow the following guidelines as prefixes.

3.5 Passing Data Between Activities and Fragments

• When passing data via Intent or Bundle between activities or fragments, the keys for different values should follow the guidelines mentioned above.
• If an activity or fragment requires parameters for its initialization, it should provide a public static function to assist with starting or creating it.

4. Resource File Conventions

4.1 Color Resource Files (color/)

This directory is specifically used to store color-related resource files.
Naming convention: type_logicalName.
For example: sel_btn_font.xml.
Colors can also be placed in the res/drawable/ directory, and referenced using @drawable, but this is not recommended. It is better to keep them separate.

4.2 Image Resource Files (drawable/ and mipmap/)

The res/drawable/ directory is used for bitmap files (.png, .9,.png, .jpg, .gif) or XML files compiled as drawable resources. The res/mipmap/ directory is used for launcher icons of different densities. Therefore, res/mipmap/ should only be used for launcher icons, while other image resources should be placed in the res/drawable/ directory.
Naming convention: type{_moduleName}_logicalName, type{_moduleName}_color.
Note: The content within {} is optional; type can be a drawable resource type or a widget type (see the UI Control Abbreviation table in the appendix). The suffix _small indicates a small image, while _big indicates a large image.

4.3 Layout Resource Files (layout/)

Naming convention: type_moduleName, type{_moduleName}_logicalName.
Note: The content within {} is optional.

4.4 values Resource Files (values/)

Files in the values/ resource directory should end with “s”, such as attrs.xml, colors.xml, dimens.xml. The file name itself is not important; what matters are the various tags under the tag. For example, < style > determines the style, and < color > determines the color. Therefore, a large XML file can be split into multiple smaller files, such as styles.xml, styles_home.xml, styles_item_details.xml, styles_forms.xml.

5. Commenting Guidelines

To make it easier for others to read your code, it is recommended to include comments in key places.

5.1 Class Comments

After completing each class, there should be a comment containing the author’s name and contact information.

/**
 * <pre>
 *     author : Blankj
 *     e-mail : xxx@xx
 *     time   : 2023/11/21
 *     desc   : xxxx description
 *     version: 1.0
 * </pre>
 */
public class WelcomeActivity {
    ...
}

5.2 Method Comments

Each member method (including custom member methods, overridden methods, and getter/setter methods) should have a method comment at the beginning of the method. You can input /** + Enter or set a shortcut for Fix doc comment (Settings -> Keymap -> Fix doc comment), and AS will generate a template for you. You just need to complete the parameters.

References:

https://github.com/futurice/android-best-practices/blob/master/translations/Chinese/README.cn.md