项目指南

 

 转至：Project Guidelines

这里你可以了解到文件命名，方法参数顺序，成员变量顺序等方面的知识。

1.项目指南

1.1项目结构

　　　　新项目应遵循的Android Gradle项目结构上定义Android Gradle插件用户指南。Theribot样板项目从开始就是一个很好的参考。

1.2 文件的命名

1.2.1 类文件

　　　　类名称是用UpperCamelCase写的。

　　　　对于扩展Android组件的类,类名应该结束组件的名称,例如:SignInActivity,SignInFragment,ImageUploaderService ChangePasswordDialog。

1.2.2 Resources files

　　　　Resources file names are written in lowercase_underscore.（小写字母下划线）

1.2.2.1 Drawable files

　　　　Naming conventions for drawables:

 

　　　　

Asset Type	Prefix	Example
Action bar	ab_	ab_stacked.9.png
Button	btn_	btn_send_pressed.9.png
Dialog	dialog_	dialog_top.9.png
Divider	divider_	divider_horizontal.9.png
Icon	ic_	ic_star.png
Menu	menu_	menu_submenu_bg.9.png
Notification	notification_	notification_bg.9.png
Tabs	tab_	tab_pressed.9.png

　　　　Naming conventions for icons (taken from Android iconography guidelines):图标命名约定(来自Android图解指南):

Asset Type	Prefix	Example
Icons	ic_	ic_star.png
Launcher icons	ic_launcher	ic_launcher_calendar.png
Menu icons and Action Bar icons	ic_menu	ic_menu_archive.png
Status bar icons	ic_stat_notify	ic_stat_notify_msg.png
Tab icons	ic_tab	ic_tab_recent.png
Dialog icons

　　　　Naming conventions for selector states:选择器的命名约定:

State	Suffix	Example
Normal	_normal	btn_order_normal.9.png
Pressed	_pressed	btn_order_pressed.9.png
Focused	_focused	btn_order_focused.9.png
Disabled	_disabled	btn_order_disabled.9.png
Selected	_selected	btn_order_selected.9.png

　　　　

1.2.2.2 Layout files

　　　　布局文件应与Android的名称组件,它们是供但移动顶级组件名称开始。例如,如果我们正在创造一个SignInActivity布局,布局文件的名称应该beactivity_sign_in.xml。

Component	Class Name	Layout Name
Activity	UserProfileActivity	activity_user_profile.xml
Fragment	SignUpFragment	fragment_sign_up.xml
Dialog	ChangePasswordDialog	dialog_change_password.xml
AdapterView item	---	item_person.xml
Partial layout	---	partial_stats_bar.xml

　　　　稍微不同的是当我们创建一个布局就是夸大了一个适配器,e.g填充aListView。在这种情况下,布局的名称与item_应该开始。


　　　　请注意,在某些情况下,这些规则将不可能适用。例如,当创建布局文件旨在成为其他布局的一部分。在这种情况下,您应该使用前缀partial_。

1.2.2.3 Menu files

Similar to layout files, menu files should match the name of the component. For example, if we are defining a menu file that is going to be used in the UserActivity, then the name of the file should be activity_user.xml

A good practice is to not include the word menu as part of the name because these files are already located in the menudirectory.

(类似于布局文件、菜单文件应该匹配组件的名称。例如,如果我们定义菜单文件用于UserActivity,然后应该activity_user.xml文件的名称一个良好的实践是不包括这个词菜单作为名字的一部分,因为这些文件已经位于menudirectory。)

1.2.2.4 Values files

Resource files in the values folder should be plural, e.g. strings.xml, styles.xml, colors.xml, dimens.xml, attrs.xml

　　(资源文件在文件夹的值应该是复数,如strings.xml、styles.xml,colors.xml,dimens.xml attrs.xml)

2 Code guidelines

2.1 Java language rules

2.1.1 Don't ignore exceptions

You must never do the following:

void setServerPort(String value) {
    try {
        serverPort = Integer.parseInt(value);
    } catch (NumberFormatException e) { }
}

While you may think that your code will never encounter this error condition or that it is not important to handle it, ignoring exceptions like above creates mines in your code for someone else to trip over some day. You must handle every Exception in your code in some principled way. The specific handling varies depending on the case. - (Android code style guidelines)

See alternatives here.

2.1.2 Don't catch generic exception(不要捕捉通用的异常)

You should not do this:

try {
    someComplicatedIOFunction();        // may throw IOException
    someComplicatedParsingFunction();   // may throw ParsingException
    someComplicatedSecurityFunction();  // may throw SecurityException
    // phew, made it all the way
} catch (Exception e) {                 // I'll just catch all exceptions
    handleError();                      // with one generic handler!
}

See the reason why and some alternatives here

2.1.3 Don't use finalizers

We don't use finalizers. There are no guarantees as to when a finalizer will be called, or even that it will be called at all. In most cases, you can do what you need from a finalizer with good exception handling. If you absolutely need it, define a close()method (or the like) and document exactly when that method needs to be called. See InputStream for an example. In this case it is appropriate but not required to print a short log message from the finalizer, as long as it is not expected to flood the logs. - (Android code style guidelines)

2.1.4 Fully qualify imports

This is bad: import foo.*;

This is good: import foo.Bar;

See more info here

2.2 Java style rules

2.2.1 Fields definition and naming

Fields should be defined at the top of the file and they should follow the naming rules listed below.

• Private, non-static field names start with m.  (私人,非静态字段名称
• Private, static field names start with s.  (私人的,静态字段名称
• Other fields start with a lower case letter. (其他领域以小写字母开始
• Static final fields (constants) are ALL_CAPS_WITH_UNDERSCORES. （静态final字段(常量)

Example: 

public class MyClass {
    public static final int SOME_CONSTANT = 42;
    public int publicField;
    private static MyClass sSingleton;
    int mPackagePrivate;
    private int mPrivate;
    protected int mProtected;
}