• 前言

最近接手的一些项目,不同的人编码风格迥异,类里的变量、方法的定义穿插,注释极为稀少,更有一些变量和方法的命名非常近似,例如表示播放队列的"playQueue"和表示歌单的"playList",wtf?

这不是一个意思吗?一些回调的时机也不能直观的看出来,通常需要debug调试多次;multi project之间值的传递、广播跨进程的发送、服务的开启和绑定,一句注释都没有,不知道过了这么久,

这些代码的同事,还能很快看懂自己写的东西吗?这简直让人抓狂啊,于是乎,写下此篇博客,吐槽别人的同时,更要引以为鉴,通过一些实际而有效的方法让自己代码更具可读性.

• 代码中行而有效的几点
  

1. 放置常量与变量的排位顺序
   • 第一层放置顺序的规则:
     常量->变量->接口->内部类.
   • 第二层,各个类型内部又区分为:
     静态static->非静态
   • 第三层,最后的一个排位规则:访问权限
     private私有->包访问(前无修饰符)->protected->public

               依据这个规则,总结如下:　类中定义变量的先后顺序

　　　　　　　　　　　　　　　　private static final int->String 私有常量String型

　　　　　　　　　　　　　　　　static final int->String 包与protected常访问权限常量

　　　　　　　　　　　　　　　　public static final int->String公共常量

　　　　　　　　　　　　　　　　private static int->String 私有静态变量

　　　　　　　　　　　　　　　　static int->String 包与protected常访问权限静态变量

　　　　　　　　　　　　　　　　public static int->String公共静态变量

　　　　　　　　　　　　　　　　private int->Stirng;普通私有变量

　　　　　　　　　　　　　　　　protect子类访问权限->public int&String 普通公共变量

　　　　　　　　　　　　　　　　接口:private static ->普通接口

　　　　　　　　　　　　　　　　内部类:private static ->普通内部类

　　2.常量&变量命令规则　　

• 以**static fina**l修饰的常量字母全都为大写，单词之间用_下划线隔开，如RESULT_CANCELED。
• 静态变量前用小写字母”s”表示，后接单词的首字母大写，如sActivity
• 除静态变量的其它所有变量前都用小写字母”m”表示，后接单词的首字母大写，如 private Window mWindow
• 一般都是用类名前加”s”或者”m”来命名一个类对象变量

　　3.方法命名规则　　

• 采用小驼峰命名法，首单词小写，第二个单词首字母大写，如getActivityToken()
• 方法名的第一个字母一般都为动词
• 常用的get,set来表示取得与设置;save保存
• on用以当什么发生的时候，生命周期都是以on开头;
• requse**t请求，如请求权限;**add添加;enter进入
• open开启对话框之类;close关闭;cancle取消;show显示,dismiss隐藏
• start启动如activity;stop停止如stop service;init初始化
• 如果方法的返回值为boolean,一般命令为isMn()或者hasMn()
• 其它boolean值的返回动词有should,can

　　4.MultiProject中注明跳转到哪里

　　一般地,Andorid中界面的跳转、广播的发送、服务的开始和绑定,都是与Intent意图相关;Intent又分为显示意图和隐式意图,显示意图需显示的设置好当前类要跳转到哪个包名下的那个类(这种跳转通常都不是

跨进程的),而一些进程间的跳转,系统服务的开启都是需要隐式跳转的,隐式跳转是根据要跳转类中定义的action和跳转到组件的action(清单文件中定义的节点信息)是否一致;通常你并不知道需要跳转到哪里;

因此,有两点是需要注意的:①action尽量定义得与跳转目标类相关,且是唯一的②要求加上明确的注释信息,跳转到的包名、类名、用途

　　5.代码中一些暂时的解决办法需注明TODO注释

　　IDE工具一般对TODO注释功能有很好的支持,可以显示和定位所有注释中出现的TODO关键字;往往一些不靠谱的解决办法或途径都是导致某个bug的隐藏因素;提前注明此为临时的解决办法,可能导致什么后果,计划后面什么时候再修,可以给后期维护和调试带来很大的便利,这一点其实及其重要,因此决定单独拿出来写一下

• 小结

　　暂时想到的就是这些了,后面遇到更坑,更让我头疼的代码,再来补充...附上找到的 常见控件缩写和常用英文单词的缩写规范表

附录：

表1 UI控件缩写表

表2 常见的英文单词缩写:

注:程序中使用单词缩写原则：不要用缩写，除非该缩写是约定俗成的。

代码可读性艺术在Andorid中的体现