关于命名

我很重视命名，在我看来，命名不仅仅是给代码的各个元素起个名字这么简单，它还反映了开发者对于语言的理解程度，对于编程技巧的掌握程度，对于业务的熟悉程度。甚至，它还反映了开发者对于代码的态度。

相信大部分的开发者写的第一个程序都是“Hello, world”。

以Java为例，一般是这样的：

package com.wenchao;

public class Hello {

     

     public static void main(String[] args) {

          System.out.println("Hello, world");

     }

}

就是这样一段简单到不能再的代码，包含了多种命名规则。

1.包名：com.wenchao。将公司域名倒序，全部小写

2.类名：Hello。首字母大写，大于一个单词采用驼峰命名规则。

3.方法名：main。首字母小写，大于一个单词采用驼峰命名规则。

4.参数名：args。首字母小写，大于一个单词采用驼峰命名规则。

5.关键字：package public class void。全部小写。

在代码的世界，命名的规则有很多种。包，类，方法，参数，变量，关键字等等代码元素，每种元素都有自己的命名规则。不同的语言之间，这些规则也不尽相同。每个团队还会制定更加细粒度的命名规则。

有了规则就需要遵守，如果不遵守，就会出现问题。而除了规则，还有其他因素会导致命名不够友好。

表意不清

这种情况出现在开发者对代码所要表达的意思理解不充分，就匆忙下手。例如：有一个方法 getList()，如果这是在一个简单的业务模型中，那么还好，可以结合包名，类名等元素去理解。但通常情况下，我们的业务模型都会比较复杂，那么这样的方法名就是灾难了，不仅别人维护的时候一头雾水，连作者过几天也会忘了自己当初写的是什么。什么？你说注释？我不认为写出这种方法的人会写注释。又或者他的注释是/** 获取列表 */。

其实这种问题很容易解决，只需要把方法名改为getXXXList()即可，表意很清晰，如果方法比较简单，连注释都省了。但这也要求开发者在动手写码之前，要多思考，充分理解业务模型，才能更好的使用命名表达意图。

过时

Java中有一个注解@deprecated，表示方法，变量等已经是过时的，不建议使用。这是因为在Java的升级过程中，开发出了更好的方法，变量等。同样，我们的代码也是不断进化升级的，这个过程中，命名的进化也是不可或缺的一部分。让命名随着版本升级，业务变化，代码重构的进行而优化，为这些工作表达出清晰的意图，摘掉命名的deprecated标签。

可读性差甚至不可读

先鉴赏一个类

public class Bean {

     public String l0;

     public String l1;

     public String l2;

     public String l3;

     public String l4;

     public String l5;

     public String l6;

}

这是我多年前见到的一个类，此类通用性之强，扩展性之优，在我的开发生涯中，堪称之最。无论你是什么样的业务模型，都可以用它表达，无论你有多少字段，统统可以装载。此类堪称万能，但你想读懂它，那是万万不能。幸好写这个类的哥们没在公司呆多久，没有扩散的太厉害，否则，要想改它，臣妾真是做不到啊。

当然，这是一个极端的例子。但是，也能反映出命名在开发中的重要程度。差的命名甚至能直接破坏你的代码结构，并且导致代码完全不可读。

最近梳理了团队的Android UI代码规范，其中多条规范涉及到命名，主要调整的是命名的顺序。以布局为例，以前的命名规则为：组件名_模块名_功能名.xml，例如：activity_transfer_upload.xml。这种命名规则在产品功能较少的时候，还能适用，查找也较为方便。但随着功能的增长，activity_xxx已经超出一屏的时候，想对一个模块进行修改就会变得很痛苦。于是我们将命名规则改为：模块名_功能名_组件名.xml，豁然开朗，一个模块的所有组件都聚集起来了，妈妈再也不用担心我找不到了。query的优化使团队修改UI部分的效率大大提高，并且由于组件都聚集起来，漏改的情况也大为减少，也降低了bug率。

在我看来，命名体现出代码的气质，反映了开发者对于细节和品质的追求。好的命名应该做到三点：遵循规则，表意清晰，持续优化。