1
AS规范
工欲善其事,必先利其器.
尽量使用最新版的IDE进行开发;
编码格式统一为UTF-8;
编辑完.java、 .xml等文件后一定要格式化(基本格式方面使用 AS 默认模板即可);
删除多余的import,减少警告出现,可利用AS的Optimize Imports(Settings → Keymap → Optimize Imports)快捷键;
AS常用开发插件可以参考这里~AS常用开发插件(#/p/c76b0d8a642d)
2
命名规范
代码中的命名严禁使用拼音与英文混合的方式,更不允许直接使用中文的方式.正确的英文拼写和语法可以让阅读者易于理解,避免歧义.
注意:即使纯拼音命名方式也要避免采用.但alibaba、taobao、youku、hangzhou等国际通用的名称,可视同英文.
2.1 包名
包名全部小写,连续的单词只是简单地连接起来,不使用下划线,采用反域名命名规则,全部使用小写字母.
一级包名是顶级域名,通常为com,edu,gov,net,org等,二级包名为公司名,三级包名根据应用进行命名,后面就是对包名的划分了,关于包名的划分,推荐使用按功能分,一开始我们也是按照层去分包的,很坑爹.
按照功能分可能你不是很好区分在哪个功能中,不过也比你按照层区分要好找很多.
package内高内聚,package间低耦合
哪块要添新功能,只改某一个package下的东西;
按class职能分层(PBL)降低了代码耦合,但带来了package耦合,要添新功能,需要改model、dbHelper、view、service等等,需要改动好几个package下的代码,改动的地方越多,越容易产生新问题,不是吗?
按功能分包(PBF),featureA相关的所有东西都在featureA包,feature内高内聚高度模块化,不同feature之间低耦合,相关的东西都放在一起,还好找
package有私有作用域(package-private scope)
你负责开发这块功能,这个目录下所有东西都是你的;
PBL的方式是把所有工具方法都放在util包下,小张开发新功能时候发现需要一个xxUtil,但它又不是通用的,那应该放在哪里?
没办法,按照分层原则,我们还得放在util包下,好像不太合适,但放在其它包更不合适,功能越来越多,util类也越定义越多.后来小李负责开发一块功能时发现需要一个xxUtil,同样不通用,去util包一看,怎么已经有了,而且还没法复用,只好放弃xx这个名字,改为xxxUtil……因为PBL的package没有私有作用域,每一个包都是public(跨包方法调用是很平常的事情,每一个包对其它包来说都是可访问的)
如果是PBF,小张的xxUtil自然放在feautreA下,小李的xxUtil在featureB下,如果觉得util好像是通用的,就去util包看看要不要把工具方法添进xxUtil,class命名冲突没有了;
PBF的package有私有作用域,featureA不应该访问featureB下的任何东西(如果非访问不可,那就说明接口定义有问题)
很容易删除功能
统计发现新功能没人用,这个版本那块功能得去掉
如果是PBL,得从功能入口到整个业务流程把受到牵连的所有能删的代码和class都揪出来删掉,一不小心就完蛋;
如果是PBF,好说,先删掉对应包,再删掉功能入口(删掉包后入口肯定报错了),完事.
高度抽象
解决问题的一般方法是从抽象到具体,PBF包名是对功能模块的抽象,包内的class是实现细节,符合从抽象到具体,而PBL弄反了;
PBF从确定AppName开始,根据功能模块划分package,再考虑每块的具体实现细节,而PBL从一开始就要考虑要不要dao层,要不要com层等等
只通过class来分离逻辑代码
PBL既分离class又分离package,而PBF只通过class来分离逻辑代码
没有必要通过package分离,因为PBL中也可能出现尴尬的情况:
├─service
│MainServ.java
按照PBL,service包下的所有东西都是Controller,应该不需要Serv后缀,但实际上通常为了码起来方便,直接import service包,Serv后缀是为了避免引入的class和当前包下的class命名冲突.
当然,不用后缀也可以,得写清楚包路径,比如new net.ayqy.service.Main(),麻烦;而PBF就很方便,无需import,直接new MainServ()即可.
package的大小有意义了
PBL中包的大小无限增长是合理的,因为功能越添越多;而PBF中包太大(包里class太多)表示这块需要重构(划分子包).
2.2 类名
类名都以UpperCamelCase风格编写.
类名通常是名词或名词短语,接口名称有时可能是形容词或形容词短语.现在还没有特定的规则或行之有效的约定来命名注解类型.
名词,采用大驼峰命名法,尽量避免缩写,除非该缩写是众所周知的, 比如HTML, URL,如果类名称中包含单词缩写,则单词缩写的每个字母均应大写.