Android代码规范_android 包名格式不正确,请填写以下划线或字母开头,可包含数字、字母、下划线和点

1.命名规范

1.1.通用规则

标识符只能使用ASCII字母和数字

1.2.各类标示符的规则

1.2.1.包名

• 包名全部小写，连续的单词只是简单地连接起来，不使用下划线；
• 采用反域名命名规则，全部使用小写字母。一级包名为com/cn，二级包名为xx（可以是公司或则个人的随便），三级包名根据应用进行命名，四级包名为模块名或层级名，如：cn.rongcloud.im.activity

1.2.2.类名

• 类名能够准确反映这个类的含义，所有单词的首字母大写，如登录界面LogInActivity，好友信息FriendInfo文件工具类FileUtils等；
• 类名都以UpperCamelCase风格编写;
• 尽量避免缩写，除非该缩写是众所周知的，比如HTML,URL，如果类名称中包含单词缩写，则单词缩写的每个字母均应大写。

1.2.3.方法名

• 方法名能够准确反映这个方法的作用，首字母小写，其他单词的首字母大写，如转换成字符窜toString（）；
• 方法名都以lowerCamelCase 风格编写；
• 方法名通常是动词或动词短语。

1.2.4.常量

• 常量名命名模式为CONSTANT_CASE，全部字母大写，用下划线分隔单词；
• 每个常量都是一个静态final字段，但不是所有静态final字段都是常量，在决定一个字段是否是一个常量时，考虑它是否真的感觉像是一个常量；例如，如果任何一个该实例的观测状态是可变的，则它几乎肯定不会是一个常量，只是永远不打算改变对象一般是不够的，它要真的一直不变才能将它示为常量。

1.2.5.非常量的成员变量

非常量字段名以LowerCamelCase风格编写；

public static final 字段(常量) 全部大写，并用下划线连起来。

public class MyClass {  
        public static final int SOME_CONSTANT = 42;  
        public int pField;  
        private static MyClass sSingleton;  
        int mPackagePrivate;  
        private int mPrivate;  
        protected int mProtected; 
        public static int gField; 
  }
1
2
3
4
5
6
7
8
9

与View相关的控件变量和普通变量

考虑到Android中使用很多UI控件，为避免控件和普通成员变量混淆以及更好达意，所有用来表示控件的成员变量统一加上控件名称作为后缀，如标题的TextView，mTitleTextView；

对于普通变量一般不添加类型后缀，标题如mTitle；

1.2.6.局部变量

• 局部变量名以LowerCamelCase风格编写，比起其它类型的名称，局部变量名可以有更为宽松的缩写；
• 虽然缩写更宽松，但还是要避免用单字符进行命名，除了临时变量和循环变量；即使局部变量是final和不可改变的，也不应该把它示为常量，自然也不能用常量的规则去命名它。

临时变量

临时变量通常被取名为i，j，k，m和n，它们一般用于整型；如：for (int i = 0; i < len ; i++)，并且它和第一个单词间没有空格。

1.2.7.资源文件

1.2.7.1.资源布局文件（XML文件（layout布局文件））：

全部小写，采用下划线命名法
* contentview命名
必须以全部单词小写，单词间以下划线分割，使用名词或名词词组。
所有Activity或Fragment的contentView必须与其类名对应，对应规则为：
1）将所有字母都转为小写，将类型和功能调换（也就是后缀变前缀）。
例如：activity_main.xml
2) Dialog命名：dialog_描述.xml
例如：dialog_hint.xml
3) PopupWindow命名：ppw_描述.xml
例如：ppw_info.xml
4) 列表项命名：item_描述.xml
例如：item_city.xml
5) 包含项命名：模块_(位置)描述.xml
例如：activity_main_head.xml、activity_main_bottom.xml
注意：通用的包含项命名采用：项目名称缩写_描述.xml
例如：xxxx_title.xml

1.2.7.2.资源文件（图片drawable文件夹下）：

全部小写，采用下划线命名法，加前缀区分
命名模式：可加后缀 _small 表示小图, _big 表示大图，逻辑名称可由多个单词加下划线组成，采用以下规则：
用途模块名逻辑名称
用途模块名颜色
用途_逻辑名称
用途_颜色
说明：用途也指控件类型（具体见UI控件缩写表）

例如：

* btn_main_home.png 按键
* divider_maket_white.png 分割线
* ic_edit.png 图标
* bg_main.png 背景
* btn_red.png 红色按键
* btn_red_big.png 红色大按键
* ic_head_small.png 小头像
* bg_input.png 输入框背景
* divider_white.png 白色分割线
如果有多种形态如按钮等除外如 btn_xx.xml（selector）
1
2
3
4
5
6
7
8
9
10

values中name命名

2.格式规范

2.1.区块划分

• 常量声明区
• UI控件成员变量声明区
• 普通成员变量声明区
• 内部接口声明区
• 初始化相关方法区
• 事件响应方法区
• 普通逻辑方法区
• 重载的逻辑方法区
• 发起异步任务方法区
• 异步任务回调方法区
• 生命周期回调方法区（出去onCreate()方法）
• 内部类声明区

2.2.类成员排列通用规则

• 按照发生的先后顺序排列
• 常量按照使用先后排列
• UI控件成员变量按照layout文件中的先后顺序排列
• 普通成员变量按照使用的先后顺序排列
• 方法基本上都按照调用的先后顺序在各自区块中排列
• 相关功能作为小区块放在一起或者封装掉

2.3.缩进标准

建立标准的缩进大小（如四个空格），并一致地使用此标准对代码进行格式化；

2.4.变量声明

不要使用组合声明，比如int a, b;。
需要时才声明，并尽快进行初始化
不要在一个代码块的开头把局部变量一次性都声明了(这是c语言的做法)，而是在第一次需要使用它时才声明。 局部变量在声明时最好就进行初始化，或者声明后尽快进行初始化。

2.5.修饰符

private：仅类的内部可获取；
protected：类及其子类可获取；
public：整个包名范围内可获取；

2.6.冗余代码

避免多余的代码，注释掉的代码和没有实际使用代码都要删掉，不要保留；

3.Javadoc注释

主要作用是便于其他人阅读和理解代码；

在每个程序的最开始部分，一般都用Javadoc注释对程序的总体描述以及版权信息，之后在主程序中可以为每个类、接口、方法、字段添加Javadoc注释，每个注释的开头部分先用一句话概括该类、接口、方法、字段所完成的功能，这句话应单独占据一行以突出其概括作用，在这句话后面可以跟随更加详细的描述段落；
虽然为一个设计低劣的程序添加注释不会使其变成好的程序，但是如果按照编程规范编写程序并且为程序添加良好的注释却可以帮助你编写出设计完美，运行效率高且易于理解的程序，尤其是在多人合作完成同一项目时编程规范就变得更加重要。

/**
     * <p>启动会话界面。</p>
     * <p>使用时，可以传入多种会话类型 {@link io.rong.imlib.model.Conversation.ConversationType} 对应不同的会话类型，开启不同的会话界面。
     * 如果传入的是 {@link io.rong.imlib.model.Conversation.ConversationType#CHATROOM}，sdk 会默认调用
     * {@link RongIMClient#joinChatRoom(String, int, RongIMClient.OperationCallback)} 加入聊天室。
     * 如果你的逻辑是，只允许加入已存在的聊天室，请使用接口 {@link #startChatRoomChat(Context, String, boolean)} 并且第三个参数为 true</p>
     *
     * @param context          应用上下文。
     * @param conversationType 会话类型。
     * @param targetId         根据不同的 conversationType，可能是用户 Id、讨论组 Id、群组 Id 或聊天室 Id。
     * @param title            聊天的标题，如果传入空值，则默认显示会话的名称。
     */ 
1
2
3
4
5
6
7
8
9
10
11
12