转至：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:

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

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

1.2.2.2 Layout files

　　　　布局文件应与Android的名称组件,它们是供但移动顶级组件名称开始。例如,如果我们正在创造一个SignInActivity布局,布局文件的名称应该beactivity_sign_in.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:

1 void setServerPort(String value) {
2     try {
3         serverPort = Integer.parseInt(value);
4     } catch (NumberFormatException e) { }
5 }

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;
}