最佳实践之Android代码规范

命名规范

包命名规范

采用反域名命名规则,包名全部小写,连续的单词只是简单地连接起来,不使用下划线,一级包名为com,二级包名为xxx(可以是公司域名或者个人命名),三级包名根据应用进行命名,四级包名为模块名或层级名。如:

com.isa.crm.activity |
com.isa.crm.adapter

JAVA类命名规范

采用大驼峰式命名法,尽量避免缩写,除非该缩写是众所周知的,比如HTML,URL,如果类名称包含单词缩写,则单词缩写的每个字母均应大写。如:

Product | ProductManager |
ProductListActivity | ProductListAdapter | JsonHTTPSRequest

接口命名规范

命名规则与类一样采用大驼峰命名法,多以ableible结尾。例如:

interface Runable | interface
Accessible

成员变量命名规范

采用小驼峰命名法

临时变量命名

使用标准的Java命名方法,不推荐使用Google的m命名法。例如:

private String userName; 而不推荐使用 private
String mUserName;

常量命名

常量使用全大写字母加下划线的方式命名。例如:

public static final String TAG = "tag";

控件实例命名

类中控件名称必须与xml布局id保持一致(可以去掉{module_name})。例如:

在布局文件中 Button 的id为: android:id="@+id/btn_pay"

private Button btn_pay;

方法命名规范

动词或动名词,采用小驼峰命名法。例如:

run(); | onCreate(); | syncProducts();

布局文件(Layout)命名规范

全部小写,采用下划线命名法。其中{module_name}为业务模块或是功能模块等模块化的名称或简称。

activity layout: {module_name}_activity_{名称} 例如:

crm_activity_main.xml | crm_activity_shopping.xml

fragment layout:{module_name}_fragment_{名称} 例如:

crm_fragment_main.xml | crm_fragment_shopping.xml

Dialog layout{module_name}_dialog_{名称} 例如:

crm_dialog_loading.xml

列表项布局命名{module_name}_list_item_{名称} 例如:

crm_listitem_customer.xml

包含项布局命名include_{名称} 例如:

include_head.xml

adapter的子布局: {module_name}_item_{名称} 例如:

qz_item_order.xml

widget layout: {module_name}_widget_{名称} 例如:

crm_widget_shopping_detail.xml

资源id命名规范

命名模式为:{view缩写}_{module_name}_{view的逻辑名称},如:

顾客管理CRM模块布局 LinearLayout 的布局id –> ll_crm_content

模块简称为qz的 ImageView 的布局id –> iv_qz_photo

常见控件View与其缩写对照参考表如下:

图片资源文件命名规范

图标命名{module_name}_ic_{名称} 例如:

crm_ic_app.png

背景图片命名: {module_name}_bg_{名称} 例如:

crm_bg_navbar_highlight_normal.9.png

按钮Button命名: {module_name}_btn_{名称} 例如:

crm_btn_login_normal.9.png

按钮checkbox图片命名{module_name}_checkbox_{名称} 例如:

crm_checkbox_cart_true.png

其他图片命名{module_name}_icon_{名称} 例如:

qz_icon_blue_circle.png

代码风格

大括号问题

风格一

if (hasMoney())
{

}
else
{

}

风格二

if (hasMoney()) {

} else {

}

空格问题

if else | while | 运算符两端 等后面需用空格隔开。例如:

规范的编写方式:

if (hasMoney()) {

} else {

}

for (int i = 0; i < 10; i++) {

}

不规范的编写方式:

if(hasMoney()){

}else{

}

for(int i=0; i<10;i++){

}

方法参数

当方法参数数量过多时,需进行换行处理.

注释

必须要对所有实例变量、类常量进行注释说明 例如:

// 用户姓名

private
String userName

必须对所有的类、接口进行注释说明 例如:

/**
* Activity基类
*
*/
public class BaseActivity extends Activity
{

}

必须对所有的方法进行注释说明 例如:

/**
* 请求
*
* @param path 路径
* @param generalParams 基本参数
* @param businessParams 业务参数
* @return 请求结果
* @throws ApiException 请求错误则返回该异常
*/
public Map<String, Object> request (String path,
              Map<String, Object> generalParams,
              Map<String, Object> businessParams) throws ApiException {

   return null;
}

更多详细也可以参考:
[Google Java编程风格指南](http://hawstein.com/posts/google-java-style.html)

驼峰式命名法(CamelCase)

  • 大驼峰式命名法(UpperCamelCase):
    每个单词的第一个字母都大写 如:XmlHttpRequest
  • 小驼峰式命名法(lowerCamelCase):
    除了第一个单词,每个单词的第一个字母都大写 如:xmlHttpRequest

说明

该篇介绍为Android项目开发过程中的一些常用的命名规范|代码编写风格规范,该规范来源于个人资料整理(参考网络技术博客)、个人项目实践。参考这些规范有助于 项目的协同开发,项目代码的风格统一、在项目的后期维护中更方便、快捷的查找、理解和修改别人的代码。如朋友们有更好的规范要求、欢迎分享出来、一起讨论。

时间: 2024-12-31 23:56:38

最佳实践之Android代码规范的相关文章

Android 代码规范

前言 这份文档参考了 Google Java 编程风格规范和 Google 官方 Android 编码风格规范.该文档仅供参考,只要形成一个统一的风格,见量知其意就可. 源文件基础 编码格式 源文件编码格式为 UTF-8. 文件名 源文件以其最顶层的类名来命名,大小写敏感,文件扩展名为.java. 源文件结构 许可证与版权信息 如果一个文件包含许可证或版权信息,那么它应当被放在文件最前面. package语句 package 语句不换行,列限制(3.4节)并不适用于package语句.(即pac

Android代码规范----按钮单击事件的四种写法

[前言] 按钮少的时候用第三种的匿名内部类会比较快,比如写demo测试的时候或者登陆界面之类. 按钮多的时候一般选择第四种写法.   一.第一种写法:在XML文件中指定(很少用) 在XML文件中显式指定控件的onClick属性,点击按钮时会利用反射的方式调用对应Activity中的onClick()方法. (1)xml文件代码如下: 1 <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"

Android夜间模式最佳实践_Android

由于Android的设置中并没有夜间模式的选项,对于喜欢睡前玩手机的用户,只能简单的调节手机屏幕亮度来改善体验.目前越来越多的应用开始把夜间模式加到自家应用中,没准不久google也会把这项功能添加到Android系统中吧. 业内关于夜间模式的实现,有两种主流方案,各有其利弊,我较为推崇第三种方案: 1.通过切换theme来实现夜间模式. 2.通过资源id映射的方式来实现夜间模式. 3.通过修改uiMode来切换夜间模式. 值得一提的是,上面提到的几种方案,都是资源内嵌在Apk中的方案,像新浪微

Android异常处理最佳实践_Android

一个好的app 异常处理机制 我认为应该至少包含以下几个功能: 1.能把错误信息上传到服务器  让开发者可以持续改进app 2.错误信息至少应该包含 是否在主进程 是否在主线程 等可以帮助程序员定位的信息 3.最好包含手机硬件及软件信息. 4.主进程引发的异常 最好交由系统自己处理 也就是让用户可以感知到 那种(当然你也可以自己定义一套更有意思的感知系统对话框等,具体可参考各种有意思的404界面) 5.子进程引发的异常最好别让用户感知到.比如push之类的 这种 和用户感知弱关联的这种.最好发生

Jenkins管道最佳实践Top 10

本文讲的是Jenkins管道最佳实践Top 10[编者的话]Andy Pemberton领导CloudBees的解决方案架构团队.CloudBees是一家依赖Jenkins实现云化持续集成平台的创业公司,目前已经得到C轮融资.Andy拥有超过十年的软件交付经验,同时他也是经常发表演讲和撰写博客.本文是Andy做为Jenkins专家给出的10条Jenkins管道化使用的最佳实践. Jenkins的管道化插件对于其用户来说是个变局者.依赖于域领域语言(DSL)Groovy,管道化插件实现了脚本化.这

《Web前端开发最佳实践》——1.3 规范的Web前端代码:更易维护、更高性能和更安全

1.3 规范的Web前端代码:更易维护.更高性能和更安全 规范的代码,这是所有软件开发中对代码的基本要求,前端开发也是一样的,要求编写规范的HTML.CSS和JavaScript代码. 什么样的前端代码才能称得上规范的代码?探讨这个问题之前,首先需要强调的是规范不是标准,不是放之四海而皆准的,不同的项目中的代码规范是有可能有差异的,比如命名,有些项目规定HTML标签的id必须要以控件的缩写名作为前缀,如按钮的id名以"btn"作为前缀,有些只是规定命名有意义就可以.再比如有些项目规定J

《Web前端开发最佳实践》——2.6 前端代码基本命名规范和格式规范

2.6 前端代码基本命名规范和格式规范 命名规范和格式规范是代码规范中最基本的规范,任何代码的混乱都是从命名和格式的混乱开始的,而意义明确的命名和规整的代码格式则提高了代码的可读性与可维护性,给代码的阅读者和维护者留下了良好的第一印象.命名规范和格式规范没有一个统一的标准,不同的人可能有不同的认识,但是在同一个项目中,必须严格遵守统一的命名和格式规范.以下推荐的规范是在实际项目中认同度较高的代码规范,供读者参考.2.6.1 HTML命名规范及格式规范 HTML代码所有的标签名和属性应该都为小写,

《C++编程规范:101条规则、准则与最佳实践》——第2章设计风格设计风格 C++编程规范:101条规则、准则与最佳实践 复杂性啊,愚人对你视而不见,实干家受你所累。 有些人避而远之。惟智者能够善加消除。 ——Alan Perlis 我知道,但是却又忘记了Hoare的至理名言:不成熟的优化是程

第2章设计风格 C++编程规范:101条规则.准则与最佳实践 复杂性啊,愚人对你视而不见,实干家受你所累. 有些人避而远之.惟智者能够善加消除. --Alan Perlis 我知道,但是却又忘记了Hoare的至理名言:不成熟的优化是程序设计中的万恶之源. --Donald Knuth[1] The Errors of TeX[Knuth89] 完全区分设计风格与编码风格是非常困难的.我们将一般在实际编写代码时才用得到的条款留到下一部分介绍. 本部分集中讨论适用面比一个特定的类或者函数更广的原则和

《Web前端开发最佳实践》——第2章 高效Web前端开发2.1 前端代码的结构组织和文件的命名

第2章 高效Web前端开发 本章首先将概述Web前端开发中的相关最佳实践,如前端代码文件组织.前端代码重构.前端框架的选择,以及前端开发过程中实用的开发辅助工具等,帮助读者提高前端开发的效率.好的开发方式在项目中会起到事半功倍的效果,并且可确保开发过程中的代码结构清晰,易维护.本章然后会介绍前端代码的基本命名规范和格式规范,良好的命名规范和规整的格式让代码看起来干净整洁,也体现了开发者良好的职业素养,应该说命名规范.整齐的格式不仅是开发过程中的一种约定,而且是程序员之间良好沟通的桥梁. 2.1