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

  • 前言

最近接手的一些项目,不同的人编码风格迥异,类里的变量、方法的定义穿插,注释极为稀少,更有一些变量和方法的命名非常近似,例如表示播放队列的"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控件缩写表

控件 缩写 例子
LinearLayout ll llFriend或者mFriendLL
RelativeLayout rl rlMessage或mMessageRL
FrameLayout fl flCart或mCartFL
TableLayout tl tlTab或mTabTL
Button btn btnHome或mHomeBtn
ImageButton ibtn btnPlay或mPlayIBtn
TextView tv tvName或mNameTV
EditText et etName或mNameET
ListView lv lvCart或mCartLV
ImageView iv ivHead或mHeadIV
GridView gv gvPhoto或mPhotoGV

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

名称 缩写
icon ic (主要用在app的图标)
color cl(主要用于颜色值)
divider di(主要用于分隔线,不仅包括Listview中的divider,还包括普通布局中的线)
selector sl(主要用于某一view多种状态,不仅包括Listview中的selector,还包括按钮的selector)
average avg
background bg(主要用于布局和子布局的背景)
buffer buf
control ctrl
delete del
document doc
error err
escape esc
increment inc
infomation info
initial init
image img
Internationalization I18N
length len
library lib
message msg
password pwd
position pos
server srv
string str
temp tmp
window wnd(win)

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

时间: 2024-10-11 07:34:20

代码可读性艺术在Andorid中的体现的相关文章

编写可读性代码的艺术

在做IT的公司里,尤其是软件开发部门,一般不会要求工程师衣着正式.在我工作过的一些环境相对宽松的公司里,很多程序员的衣着连得体都算不上(搞笑的T恤.短裤.拖鞋或者干脆不穿鞋).我想,我本人也在这个行列里面.虽然我现在改行做软件开发方面的咨询工作,但还是改不了这副德性.衣着体面的其中一个积极方面是它体现了对周围人的尊重,以及对所从事工作的尊重.比如,那些研究市场的人要表现出对客户的尊重.而大多数程序员基本上每天主要的工作就是和其他程序员打交道.那么这说明程序员之间就不用互相尊重吗?而且也不用尊重自

《编写可读代码的艺术》---变量和可读性

对变量的草率使用,会导致程序的难以理解,原因是以下几点 变量越多,就越难以全部跟踪他们的动向 变量的作用域越大,就需要跟踪它的动向越久 变量改变的越频繁,就越难以跟踪它的当前值. 下面来讨论如何改善这些问题. 1 减少变量 仅当我们需要的时候,才使用变量,下面将列举出一些没必要存在的变量的. 1.1 没有价值的临时变量 一般有经验的程序员是不会刻意写个没有价值的临时变量.造成临时变量没有使用价值的原因,可能是多次修修改改之后遗留的结果. 来个日期赋值的例子 DateTime now = Date

《编写可读代码的艺术》读书笔记

表面内容 1.代码的写法应当是别人理解他所需的时间最小化.一条注释可以让你更快理解代码.尽管减少代码行数是一个好目标,但是八里街代码所需的时间最小化是一个更好的目标. 2.选择专业的词,比如函数名使用getxxx(),这个get没有表达出很多信息,是从缓存中得到?从数据库中得到?或者从网络得到?如果是网络,可以用更专业的fetchxxx()或者downloadxxx() 3.tmp,retval这样泛泛的名字,可以根据情况命名,比如tmpFile,让人知道变量是一个临时的文件.(tmp这个名字只

编写可读代码的艺术笔记

编写可读代码的艺术 表面层次上的改进 命名.注释以及审美--可以用于代码库每一行的小提示. 简化循环和逻辑 在程序中定义循环.逻辑和变量,从而使得代码更容易理解. 重新组织你的代码 在更高层次上组织大的代码块以及在功能层次上解决问题的方法. 精选话题 把"易于理解"的思想应用于测试以及大数据结构代码的例子. 第1章:代码应当易于理解 1.代码应当易于理解. 2.代码的写法应当使别人理解它所需的时间最小化. 第一部分:表面层次的改进 第2章:把信息装到名字里 1.使用专业的单词. 2.避

读书报告之《修改代码的艺术》 (I)

<修改代码的艺术>,英文名<Working Effectively with Legacy Code>,中文翻译的文笔上绝对谈不上"艺术"二字,愧对艺术二字(当然译者不是这个意思).书中第三部分不论是例子还是解说都有点混乱,远不如<重构--改善既有代码设计>一书.此书精华在于第一.二部分. 如何学习这本书,作为一个最底层的码农,作为长期在别人代码上修修补补的苦逼二手货开发人员,我只能给的建议就是:你可以将它看做是如何做定制功能的指导书--从某种意义上

《编写可读代码的艺术》——简单总结

上个月好像冥冥中自有安排一样,我在图书馆看到这本 <编写可读代码的艺术> ( The Art of Readable Code) 期间因为工作的原因,停停看看,这几天终于看完了,可以大概总结如下: 1. 把信息装进名字里,给变量起个好名字 2. 审美,把代码分成段落,对齐 3. 应当取个好名字,而不是用注释去粉饰它 4. 用注释记录你的思想,比如当时为什么要这样写,记录开发过程中有哪些思考 5. 将自己代码中的不足和瑕疵记录下来,方便今后别人的维护,不要顾忌别人的看法! 6. 注释应该言简意赅

读书报告之《改动代码的艺术》 (I)

<改动代码的艺术>,英文名<Working Effectively with Legacy Code>,中文翻译的文笔上绝对谈不上"艺术"二字.愧对艺术二字(当然译者不是这个意思).书中第三部分不论是样例还是讲解都有点混乱,远不如<重构--改善既有代码设计>一书. 此书精华在于第一.二部分. 怎样学习这本书,作为一个最底层的码农,作为长期在别人代码上修修补补的苦逼二手货开发者,我仅仅能给的建议就是:你能够将它看做是怎样做定制功能的指导书--从某种意义

如何提高代码可读性

一.要提高的代码的可读性,可以从以下几方面努力 1. 清晰地表达意图 2.好的变量.方法.类名 3. 一个变量.类.方法只做一件事 4. 同一个方法体内,保持相同的抽象层次 5.一致的缩进,一致的格式 6. 不要重复自己(避免手动的复制与粘贴代码) 7. 减少“语法噪音” 8.减少代码中的嵌套级别 9. 命名时取有意义的名字,避免不规范的缩写 二.具体的提高代码的可读性的做法 1.先写注释,再写代码:理清思路再动手 (1)清晰的思路是编程行动的良好指南 花点时间思考一下,不要一接到任务就动手编代

读《软件驱魔》调试和优化遗留代码的艺术

读<软件驱魔> 调试和优化遗留代码的艺术 软件维护方法论的书,其间还有作者的感悟,读起来情深意切啊 此书中文版,第一版是2014年5月 内容给人感觉作者早已成书多年了.但软件知识还是有不过时的东西. 软件发展到现在,在我们身边,已经可以发生着许多书中的故事. 如大量的历史代码无人维护或者是开发人员不可寻且没有文档,没有流程图等等. 在这种情况下,作者指点读者去如何做更有益. 用了许多方法,并科学的介绍了不只一种方法. 收益良多. 还介绍了可能会出现的人员交流的问题.这种问题我在工作中也是常遇到