Android 架构设计(五)：命名规范与层级规范

同系列传送门：

Android 架构设计(一)：设计模式分析_深海呐的博客-CSDN博客_安卓开发框架设计模式

Android 架构设计(二)：分包和文件结构_深海呐的博客-CSDN博客

Android 架构设计(三)：技术选型_深海呐的博客-CSDN博客_android 技术选型

Android 架构设计(四)：组件化？_深海呐的博客-CSDN博客

命名规范：

程序包： com.xxx.xxx

主要强调其唯一性，一般使用公司域名/简写+APP简写，全小写。

比如：

• 微信包名：com.tencent.mm
• 淘宝包名：com.taobao.taobao

业务包： xxx

一般为全小写的单个单词，主要强调其业务范围，业务类型或者功能

比如：

• controller
• activity
• view
• utils

类：XxxXxx

一般使用大驼峰命名法。主要强调该类的作用与所属类型

比如：

• MainActivity 作用：Main程序入口界面；所属类型：Activity窗口界面。
• StringUtils 作用：String字符串处理工具；所属类型：Utils工具类
• UserDataAdapter 作用：UserData用户数据适配器；所属类型：Adapter适配器

方法：xxxXxx

一般使用小驼峰命名法。主要强调具体功能与动作

比如：

• getUserName 功能：获取用户数据；动作：get 获取
• saveUserData 功能：保存用户数据；动作：save 保存
• initView 功能：初始化View，动作：init 初始化

变量：mXxx & xxxXxx

一般使用小驼峰命名法。主要强调见名知义

   全局变量 :

        通常在前面加一个“m”，比如：

• mUserDataAdapter，mUserDataViewModler，mDataList；

   局部变量

        通常为实例的小写，比如：

• userDataAdapter，userDataViewModler，dataList；

常量：XXX_XXX

一般使用全大写字母，并使用下划线隔开每一个单词。强调见名知义。

比如：

• USER_TAG，SECRET_KEY，APP_ID；

Layout布局：xxx_xxx

一般使用全小写字母，并使用下划线隔开每一个单词，强调类型和用途。

比如：

• activity_main，强调类型：activity 视图页；强调用途：main 首页
• fragmengt_user，强调类型：fragmengt 碎片页/局部；强调用途：user 用户主页/局部
• item_user_list，强调类型：Item 某列表的子条目；强调用途：user_list 用户列表

控件ID：xxx_xxx

一般使用全小写字母，并使用下划线隔开每一个单词，强调唯一性和见名知义。

        关于控件ID的命名，有两种主流的命名方式：

第一种“控件类型+作用”，

比如：

• text_view_user_name，强调类型：TextView；强调作用：user_name用户姓名
• tv_user_name，强调类型：TextView(简写)；强调作用：user_name用户姓名
• layout_user_info；强调类型：Layout ；强调作用：user_info 用户信息

第二种“控件位置+作用”

比如：

• main_title，强调位置：main首页；强调作用：title标题
• main_user_name，强调位置：main首页；强调作用：user 用户姓名
• main_user_head；强调位置：main首页；强调作用：user 用户头像

深海强烈强调：控件ID命名的唯一性必须保证，作用必须体现！

反面举例：

图中RecyclerView的ID命名有两个问题：

1.唯一性没有保证！

当你想在代码中反向追溯的时候，无法立即从代码定位到布局文件对应的位置。

2.作用没有体现!

假如你的布局中有多个RecyclerView，无法合理进行区分，无法通过ID立即知道当前RecyclerView的职责作用。

图中还有哪些问题？

红框框中的控件ID命名过度简写问题，“rl”很难让人第一时间想到这是RelativeLayout，关于layout的命名前缀，我不建议过度简写。

命名规范的通用禁止：

关于命名规范的通用禁止，深海总结了以下三点：

1.非特殊情况，禁止使用拼音和数字；

错误示范：变量yongHuData(用户数据)   类Activity1    变量x1 x2  x3 

特殊情况举例：包名com.taobao.taobao   部分包名用了拼音确实正常情况，这和公司的简写有关，也和部分大项目的立项命名有关。还有部分变量或者类用了拼音是正常情况，比如某某三方SDK的实例变量，或者公司项目立项类型的命名，XXXUtils,XXXActivity，这里的XXX代表公司项目简写，可能是拼音，也可能是特殊含义的字母。

2.见名知义，禁止过度简写，禁止长度过长；

错误示范：

        过度简写：StringBuilder sb = new StringBuilder()

        长度过长：StringBuilder userDiskFileWriterStringBuilder = new StringBuilder()

3.方法名和变量名禁止首字母大写，便于区分类和变量的区别

错误示范：StringBuilder UserStringBuilder= new StringBuilder() 

层级规范：

类层级：

        所有类必须放在规定的包下面。

        比如：activity包下只允许放XxxActivity类，utils包下只允许放XxxUtils类

代码层级：

        类中的代码不可以职责混乱和交叉。

        比如：某Activity类代码中参杂了很多工具方法，这些方法本来要放在工具类中。这种错误导致别的类使用该方法时无法复用，更加错上加错的行为是别的类用到时去copy方法。

---

更加细节的层级问题深海有专门总结程序设计的六大基本原则，请移步：

程序设计六大原则-概况与举例_深海呐的博客-CSDN博客_程序设计的原则总结设计原则其实很早以前就在想了，但是起初我认为固定的原则会局限人的创新思维，陈旧的定律不一定是最好的。实际上随着代码量的沉积，你会发现无形之中你的程序设计会和这六大原则不谋而合。大道至简，前人走过的路，可能也是你将要走的路。原则一：单一职责这一块不管你写前端还是后端的项目，你会明白，所谓的设计模式（如MVC，MCP）就是帮助你实现部分代码的单一职责，就像是流水线上工作流程拆分，很多简单的步骤实现庞大的逻辑。当职责变得单一时，复用性提高，个体业务逻辑难度降低。这个原则算是应用最广，也最显而易见的。https://blog.csdn.net/qq_39731011/article/details/122705212

结语：

关于架构设计的总结，深海目前先总结到这里，以后会不会再写《架构设计(六)》《架构设计(七)》呢？其实我没有想好，因为这里面的东西太多了，自己知道的却很少，但是深海愿意不断的学习和不断的进取，希望能够跟大家分享更多的想法。

如果您感觉深海写的不错的话，请给文章点个赞吧，感谢各位的支持！