《代码整洁》笔记第一篇

small1

从今天开始准备看《代码整洁之道》这本书,在这本书的序里面有这样一句话“神在细节中”,我对这句话的理解就是写代码就像建楼房一样。每一个类名,方法名,接口就像建筑中的砖块和钢筋一样,质量不好的砖块可能会对建筑造成破坏性的伤害,而不整洁,不规则代码命名规范也会对程序造成一定的伤害。所以我认为在我们开发工作中,要着重的注意代码整洁性,规范性。

怎样才能写出整洁的的代码?

整洁代码就行绘画一样,多数人都知道一副画的好坏,但是能分别好坏并不表示懂的绘画,能分别代码的好坏,并不代表能写出好的代码。就像上文所说一样,想要写出整洁代码,首先要从最基本的命名开始做起

命名的规范

名副其实

命名在我们编码中肯定会遇到过,但是你每次命名都会名副其实吗,会不会有的时候因为偷懒写出下面的代码

1
int d = 1;//消逝的时间

这个d什么都没有说明,没引起对时间的感觉,再来看看下面的写法

1
int daySinceCreation

这种写法是不是感觉就来了。

再来深入的看一下

1
2
3
4
5
6
public List<int []> getThem(){
List<int []> list1 =new ArrayList<>();
for(int[] x : theList)
if(x[0] == 4)
list1.add(x);
return lits1;

上面的代码意思很模糊 theList 是什么鬼?值的4 是什么意思?这个返回的list用来做什么?

1
2
3
4
5
6
7
public List<int []> getFlaggedCells(){
List<int[]> flaggrdCells = new ArrayList<>();
for<int [] cell : getBoard)
if(cell[STATUS_VALUE] ==FLAGGED)
flaggrdCells.add(cell);
return flaggrdCells;
}

现在比如做一个扫雷游戏,盘面的名字theList的单元格列表,那改名为getBoard,盘面上每个单元格用一个简单的数组表示,4表示一种“已标记” 这样就比刚才清晰多了。我们还可以把cell[STATUS_VALUE] ==FLAGGED封装成一个方法比如isFlagged(),这样就更简化了

避免误导

别用accountList指称一组账号除非他真的是List类型的,可以改为accountGroup,这样就不会误导别人以为accountList是一个集合,命名的是要避免两个词太相近 。比如要是辨别ZHYControllerForEfficientHandlingOfStrings 和 ZHYControllerForEfficientStorageOfStrings这两个词要花多久?这两个词太相近了。

“0”, “o” ,“O”,“l”,“1”这些看起来就很像的尽量不要使用

做有意义的区分

“info”,“data“ 这种意思差不多单词不要一起使用它们就像”a”,”an”,”the” 一样,不要有废话
NameString 不会比 Name 更好,Customer和CustomerObject没有区别。

使用读得出来名称

getymdhms()这个函数你能看出来什么意思吗,可能脑洞比较的人会想到这是一个获取时间戳的放法 ,不好看也不好读,再给别说代码的时候也不能读成“盖特 ymdhms”吧,那就太尴尬了。那么写成gettimestamp()

使用可以马上搜索出来的名称

我以前在写fragment的时候在oncreat()方法中生成的view直接起名为view,有时候需要找他的时候就麻烦了,一搜索view 出来好多textview,imageview ,viwepager。这样会使我们读自己代码的时候很困难。
还有一些数字常量 比如“1”,要是在代码中搜索“1”也可以搜索出很多带有“1”的代码
搜索应该把这种常量用一个有特点的名称来声明比如int MAX_VALUES = 1;
搜索“1”困难,但是搜索MAX_VALUES就容易了吧

接口和实现

接口的命名一般都是“IXXXXX”比如”IShapeFactory”,但是应该命名“ShapeFactoryImp”接口实现比接口的定义重要!!!

不要使用单字母命名

除非在for循环里面“i”,“j“ 的时候可以用在其他时候千万不要用

类的命名

类的命名不应该是动词

方法名

方法名应该是动词或者一个短语,比如postPayment,save,deletePage等。

别卖萌

比如写杀死进程kill()别写成goDie()之类的

每个概念对用一个词

比如Controller和Manage要用就用一个,两个在一起用很难区分开。

最后的话

取好名字最难的地方在于良好的描述技巧和共有的文化背景,我们在以后的开发中要保证不要偷懒而且命名之前一定仔细推敲一下,保持格式统一,这样对以后的review 和 别的同事看你的代码都有很大的好处,好的代码看起来像作文一样流畅,所以我们仔细的命名我们的代码