代码整洁之道札记：有意义的命名

前言：英语虽然才3级，奈何却阻止不了我征服英语的勇气，哈哈，有意义的命名，那必须要倾尽我的所有英语才华，去实现代码的整洁啊。

名副其实

这个说起来容易，做起来难，我们的母语是汉语，最熟悉的是汉语拼音，所以我们在新建一个类名、方法、变量时，第一刻的印象是由拼音组成的；另外由于项目参与者的英语水平又参差不齐，又会产生混乱。

public class Time {
 private long time1;
 private long time2;
 private long time3;
 private long time4;
 private long time5;
 private long time6;

看到这个类，你肯定不知道这个类是想要干嘛的，那么如果要按照名副其实的原则来改造，那么就应该如下：

/**
* @ClassName: SpendTimeForTrading
* @Description: 记录交易用时。
* @author maweiqing
* @date 2015年5月11日 上午9:09:42
*  
*/
public class SpendTimeForTrading {
 private long checkOrderTime;
 private long tradeMatchTime;
 private long updateMoneyTableTime;
 private long dealQuotationTime;

另外，代码中尽量不要出现这样的代码

if (trade.getOrderType()==0) {

别人不知道0是什么，就看不懂你的条件到底是为了判断什么，应该修改为这样

if (trade.isContract()) {

public boolean isContract() {
  return this.getOrderType().intValue() == CONTRACT;
 }

public static final int CONTRACT = 0;

这样别人很清楚你的代码是判断什么，并且如果0的约定修改为1，那修改起来就只需要把CONTRACT = 1就行了，不需要在代码中苦苦搜寻trade.getOrderType()==0了。

注意：切记，在封装bean的时候，如果你有这样的代码

private int buy;

 public int getBuy() {
  return this.buy;
 }

 public void setBuy(int buy) {
  this.buy = buy;
 }

 public boolean isBuy() {
  return this.getBuy() == 0;// 假设0现在代表是买，为方便示例，不再建立常量
 }

如果你要用fastjson进行序列化或者反序列化

CleanCode code = new CleanCode();
  code.setBuy(1);

  System.out.println(JSON.toJSONString(code));

你认为会输出什么呢？
答案是

{"buy":false}

why？为什么，因为isBuy其实也是getter的一种写法，工具类在序列化的时候，会先序列化get对应的buy，接着再序列化is对应的buy，而放入到map时，is会将get覆盖，而is的field类型是Boolean，而buy的是int。如果把isBuy放到getBuy前面的，得到的答案就会是

{"buy":1}

当然我来举这个例子的好意不是让你置换顺序，而是告诫你，如果你有类似这种写法，请改正为如下方式：

private int buy;

 public boolean typeOfBuy() {
  return this.getBuy() == 0;// 假设0现在代表是买，为方便示例，不再建立常量
 }

 public int getBuy() {
  return this.buy;
 }

 public void setBuy(int buy) {
  this.buy = buy;
 }

避免误导

这个着我想起，很多老师在教学生编程的时候，特别喜欢写这样的例子

System.out.println(10 == 1O);
  System.out.println(101 == 10l);

我当时特别讨厌这样的例子，虽然是为了反面教材，但是让我的记忆当中充斥这这种错误例子。

还有，很多时候，有这样的代码

String msgs = new String("1");

莫名其妙的在msg上加上s，当然还有更坑爹的。

做有意义的区分

假如在一个方法内部，你需要记录时间差，你写成这样

long t3 = System.currentTimeMillis();
// 更新资金表
dealVrailMoney(this.getVarialMoneys());
long t33 = System.currentTimeMillis();
time.setUpdateMoneyTableTime(t33 - t3);

我们都还可以接受，毕竟做太多无畏的区分没有必要。
但是更多时候还存在这样的代码

public static String formatDateToDashByLong(Long date) {
public static String formatDateToDashByInt(Integer date) {

不知道为什么非要加上ByLong、ByInt！

使用读得出来的名字

很多时候，我们习惯按照自己的喜欢随意造词，只要编译器能够通过，我们才不管别人是否能够将名字读出来，但是这个做法的确很不好，很不友好。

每次看到恒大淘宝队，就感觉别扭。

使用可搜索的名称

这个尤其是对那些常量来说，如果不能够将经常用到的值存成一个代表有含义值的常量存在，简直就是遭罪。

/**
  * 买 0
  */
 public static final int BUY = 0;

 /**
  * 订立 0
  */
 public static final int CONTRACT = 0;

如果不把0存成各为其主的常量名字，当你需要变更的时候，你就痛苦了。

避免使用编码

我也很习惯使用这样的标识

int numInt;
String numString;

然而细想想这样很糟糕，多此一举啊。

最初在写构造方法的时候，习惯写这样的代码

private int num;
public Num(int i_num) {
    num = i_num;
}

直到后来才知道使用this关键字来替代，显然this关键字的写法更好。

在最初定义接口的时候，我习惯这样写：

public interface FanyongInterface {//我不太清楚返佣的英语怎么写，没有找到返佣的英语单词，姑且这样写着

但我更应该这样写

public interface Fanyong {

实现类的名字可以为FanyongImp，这样在调用的时候就可以直接使用Fanyong而不是FanyongInterface。

避免思维映射

这里我想用互联网上一句名言来说明“任何傻瓜都能写出计算机可以理解的代码，而好的程序员能写出人可以读懂的代码”。太多时候，我们对于名称的命名含糊不清，搞不懂我们写这个名称到底要代表什么。

对于类名、方法名，我们尽量用名词声明类，动词表示方法。

这里我把作者的建议重复下来：

别把名字装扮的太过可爱。

每个概念对应一个词。（不要让manager和controller在一起）

别用双关语。

添加有意义的语境。

/**
  * 5已申报
  */
 public static final int GODOWN_DECLARED = 5;
//用来表示仓单
 /**
  * 6已匹配
  */
 public static final int GODOWN_MATCHED = 6;

不要添加没有用的语境。

class Godown {
    private static final int GODOWN_DECLARED = 5; //这就不太合适了
}

总之：有意义的名字，似乎对于我们国人来说难度大了点，我自己也时常因为这而苦恼，因为英语实在不敢恭维，于是什么有道词典了，微软词典了，就是电脑上必装的。取好一个名字很重要！