Java Nameing Conventions

前网景通讯公司（Netscape）知名工程师 Phil Karlton 也说过：

There are only two hard things in Computer Science: cache invalidation and naming things.

命名非常能体现一个工程师的基本编码素养，命名的好坏，对于代码的可读性非常重要，甚至起到决定性作用。混乱的命名不仅让我们对代码难以理解，更为糟糕的是会误导我们的思维，导致对代码理解完全错误，相反良好的命名，则可以让我们的代码非常容易正确表达事物以及逻辑。大到项目名，包名，模块，对外暴露的接口，小至类名，函数，变量，参数都难以避免”命名”这个困扰。取一个良好的名字是一件非常困难的事情，即便是母语是英语的程序员而已，想要取一个能准确表达含义的名字，也是一件非常困难的事情，如上所示。对于天朝这些母语非英语的程序员来说，更是难上加难(比如我这种英语学渣)。

在日常编码工作中，实在想不到好名字的时候，可以采用变量名命名神器(CODELF) 来辅助我们进行变量命名，注: 本人有幸在项目中通过它来辅助自己的命名，个人感觉帮助并不是很大，只能作为参考。

多长才是最合适的?

我们在进行命名的时候，是应该写一个很长的命名，还是一个简短的命名，这是一个非常有争议的问题，有时感觉命名一定要准确表达含义，长一点也没关系，还有另外一类代表派系则主张简短的命名方式。能缩写就尽量缩写。如果是你你是喜欢长一点还是短一点？

尽管长的命名可以包含更多的信息，更能准确直观的表达意图，但如果变量的命名很长，那它们共同组成的代码语句就会很长，甚至超出编辑器代码长度限制，就会被编辑器换行切割成多行的情况，这会影响代码的可读性。在命名能足够表达其含义的情况下，命名其实越短越好。当然短的命名没有长的命名那么更能达意。对于那些比较常见的词，推荐使用缩写的方式，既能让命名短一些，又能不影响阅读理解。比如： VO (View Object)， DTO (Data Transfer Object ), DO (Domain Object), str (String), num (Number), 除此之外对于作用于比较小的变量，我们可以使用相对较短的命名方式。比如一些函数内的零时变量，循环迭代的下标索引等。相反，对于类名这样作用域比较大的，更推荐用长的命名方式。对于代码的作者而言，自己对代码的逻辑非常清楚，总感觉采用什么样的命名都能达意，对于需要接手你代码的同事来讲，可能就不这么认为，在编写代码的时候，我们一定要学会换位思考，假设自己不熟悉这块代码，从代码阅读者的角度去思考命名是否足够直观。

利用上下文简化命名


public class User {
  private String userName;
  private String userPassword;
  private String userAvatarUrl;
  // 省略Geeter Seeter  
}

在上述类上下文中，我们没有必要在成员属性的命名添加user作为命名前置，而是直接命名为 name, password, avatarUrl。在使用属性的时候，我们可以很友好的借助对象上下文，表达也足够明确，如下：

1 2	User user = new User(); String name = user.getName();

函数的参数也可以借助这个上下文来进行简化命名，如下：

// Bad
public void uploadUserPic2Oss(String userPicImageUri);

// Good
public void uploadUserPic2Oss(String ImageUri);

如何命名一些特殊的类

接口类在阿里巴巴编程规范手册中推荐的方式 , 在接口类命名前面加前缀 “I”，表示这是一个接口(Interface)，如 IUserService ，已至对应的实现类添加Impl后缀，如 UserServiceImpl。对于接口的命名我个人更加倾向于不添加“I”前缀的方式，如 UserService, 对于的实现类可以添加Impl后缀。但是如果在团队中大家约定了方式，那么一定要跟Team 保持Match。

抽象类跟接口类一样，两种方式，通过添加统一的前缀这里为 “Abstract”，如 AbstractChannelHandlerDelegate (dubbo 服务消费者发送消息服务提供者接受消息) ，另外一种不带前缀 “Abstract” 。无论使用那种命名方式都是可以的，项目能够统一就ok。