Android Coding Style
不错的 Android Coding Style,推荐大家在学习和开发过程中可以使用
转自 https://github.com/LoranWong/Android-Code-Style
Table of Contents
- 1 Project structure 工程结构
- 2 Package Manner 包管理规范
- 3 File Naming 文件命名
- 4 Inside Code Naming 代码内部命名
- 5 Code Manner 代码规范
- 6 Constant 内部类解析
- 7 Git 提交规范
1 Project structure 工程结构
1.1 Notice 说明
New projects should follow the Android Gradle project structure that is defined on the Android Gradle plugin user guide. The BoilerPlate project is a good reference.
新建工程需要按照最新的Android Gradle的工程结构,在以下定义:Android Gradle plugin user guide. 该工程: BoilerPlate 是一个很好的参考材料
1.2 Resources directory structure 资源文件夹结构
1 | res |
2 Package Manner 包管理规范
2.1 General 通用
1 | package name : com.chuxin.[project name] |
2.2 App 包结构
1 | * app |
3 File Naming 文件命名
3.1 Class files 类文件命名
Class names are written in UpperCamelCase.
For classes that extend an Android component, the name of the class should end with the name of the component; for example: SignInActivity
, SignInFragment
, ImageUploaderService
, ChangePasswordDialog
.
For utilties class , the name of the class should start with its usage , and ends with Utils
; for example: HttpUtils
, ImageUtils
类命名方式采用
大驼峰
命名法
对于继承自安卓组件的类来说,类名应该以该组件名结尾,例如 :
SignInActivity
,SignInFragment
,ImageUploaderService
,ChangePasswordDialog
.
对于工具类来说,命名方式应该以其完成功能开始,以
Utils
结束 ,例如 :HttpUtils
,ImageUtils
.
3.2 Resources files 资源文件
Resources file names are written in lowercase_underscore.
资源文件以小写加下划线的方式命名
3.3 Drawable files
Naming conventions for drawables:
drawable 文件的命名规范
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:
icons文件的命名规范
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 | ic_dialog |
ic_dialog_info.png |
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 |
3.4 Layout files 布局文件
Layout files should match the name of the Android components that they are intended for but moving the top level component name to the beginning. For example, if we are creating a layout for the SignInActivity
, the name of the layout file should be activity_sign_in.xml
.
布局文件的命名需要与他所嵌入的安卓组件匹配,但是将组件名称前移到开始处,例如,我们要创建一个名字为
SignInActivity
, 其名字应该为activity_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 |
4 Inside Code Naming 代码内部命名
1 | Important : 请不要使用拼音以及数字!!! |
4.1 Class Variable Naming 类变量命名
- 公有变量按
小驼峰
法命名 - 私有 & 非静态成员变量以
m
开头 - 私有 & 静态成员变量以
s
开头 - 常量以大写字母和下划线
_
组成 - 尽量使用
功能/描述 + 类型
的模式 ,如mNameTextView
- 类中变量的组件类型请不要使用缩写
- 注意不要使用
aa
bb
cc3
这种变态的命名方式 !! - 类变量过多时请
分块摆放
并且写好注释
接口类
请直接定义在类的最后
Example:
1 | public class MyClass { |
4.2 Class Method Naming 类方法命名
类方法采用
小驼峰
命名法根据函数所完成功能命名 , 如
changView()
在函数头写对于函数功能、参数和返回值的注释,如:
1
2
3
4
5
6
7
8
9
10/**
* 获取两个数中最大的一个
*
* @param value1 参与比较的第一个数
* @param value2 参与比较的第二个数
* @return 两个参数中最大的一个数
*/
public int max(int value1, int value2) {
return (value1 > value2) ? value1 : value2;
}一个函数请尽量保持在
50行
之内 !!
4.3 layout.xml 布局文件变量命名
id
以所在组件_类型_命名
的模式,例如:@+id/main_tv_name
、@id/chat_btn_send
- 布局多处重用的请使用
<include>
标签 - 所有文本请定义在
strings.xml
中 , 如@string/app_name
- 重用dp请定义在
dimens.xml
中 , 如@dimen/entry_item_height
- 对应组件缩写表:
Component 组件 | Abbreviation 缩写 |
---|---|
Fragment | fgm |
TextView | tv |
ImageView | iv |
Button | btn |
EditText | et |
LinearLayout | ll |
ReleativeLayout | rl |
normally : FirstSecond | fs |
4.4 strings.xml dimens.xml colors.xml xml变量命名
遵循
完整性
规范性
有序性
原则
- 分块并注释, 将 使用在不同的
Activity
或者Fragment
中的xml
变量 进行分块 - 命名举例 :
login_error_tips
instrings.xml
login_error_tips_height
indimens.xml
login_error_tips_bg
incolors.xml
Prefix 前缀 | Description 描述 |
---|---|
error_ |
An error message |
msg_ |
A regular information message |
title_ |
A title, i.e. a dialog title |
action_ |
An action such as “Save” or “Create” |
4.5 额外注意
Good | Bad |
---|---|
XmlHttpRequest |
XMLHTTPRequest |
getCustomerId |
getCustomerID |
String url |
String URL |
long id |
long ID |
5 Code Manner 代码规范
This is good
1 | if (condition){ |
This is bad:
1 | if (condition) body(); // bad! |
This is good:
1 | <TextView |
This is bad :
1 | <!-- Don't do this! --> |
6 Constant 内部类解析
Constant
* `CODE` --> `request_code`,`app_key` 等
* `CONFIG` --> 项目的配置变量, 偏向于调试开发使用,如:`IS_DEBUG`, `SHOW_LOG`
* `URL` --> 网络地址相关
* `COUNT` --> 某些约定的数字,如一次刷新显示的条目数量。__一定要有注释__
* `PATH` --> 路径信息,SD卡路径等
* `KEY` --> 键值对的键的信息,如 `Bundle` 中的键
7 Git 提交规范
基本要求
- 分段
例子:
1 | (Git test) Modify CircleImageView to show rounded rectangle |
第一行: 作为标题,这在 Git 中就会做为默认显示的部分,如图中深黑色字:
第二行: 留空!因为通常在设置了邮件提醒的 Git 系统中,第二行的空行是作为分隔标题和正文的存在。
第三行: 开始就是详细说明了。可以加上对此次修改的问题的链接,或者描述。如果有用到 issue
的话可以写上 issue #[issue id]
,或者附上 trello 的链接。
建议全部用英文写,其他字符有乱码的可能。 并不会乱码
- 粒度
说的是做的修改的粒度。如果你一天做了很多的修改,但是就只提交了一次,那么你的粒度就有点大了。
这样在你描述你的行为的时候就会显得模糊,如果你详细描述的话,提交信息会变得长篇大论。
但也不要做一点提交一点,这样粒度就会变得太小,会导致一天到晚在写提交信息,没有必要。
在我看来,这个事情真的只能凭感觉提交,用经验来做判断。因为一个BUG可能可大可小,大的话,你就得分割修复。
如果小,那么就一次提交修复就可。
粒度的掌握绝对会影响你的提交信息,因为二者是一一对应的。
- 宽度
是的,是宽度,不是长度。
和代码一样,如果你平时注意的话,就不要让你的代码在一行上超过80,不然谁读代码都不好受,包括你自己。
所以提交信息的宽度也有限制。
分别是标题不要超过50,内容部分不要超过70。
大概大家都会的没什么用的小Tips:
- 使用
git commit
命令并进入Vim
编辑提交信息,写完后按Esc
确保不在编辑状态,然后输入:wq
回车退出并提交。 - 直接使用
Android Studio
自带的 VCS 也很方便。
参考资料: