给变量起简短的名字
1.命名中无需含有表示变量或参数类型的单词
如果使用如Java之类的静态类型语言，开发者通常知道变量的类型。由于方法的实现一般都比较简短，所以即便是在查看一个需要推断才知道类型的本地变量，或者在code review等静态分析器不可用的情况下，我们也可以通过多看很少的几行代码就能知道变量的类型。
// 不好的:
String nameString;
DockableModelessWindow dockableModelessWindow;
// 改进:
String name;
DockableModelessWindow window;
2.对于集合(方法命名也一样)来说，最好使用名词的复数形式来描述其内容，而不是使用名词的单数形式来描述。
如果开发者更在乎集合中存储的内容， 那么变量命名应当反映这一点。
// 不好的:
List<DateTime> holidayDateList;
Map<Employee, Role> employeeRoleHashMap;
// 改进:
List<DateTime> holidays;
Map<Employee, Role> employeeRoles;
3.省略命名中不是用来消除歧义的单词
有些开发者倾向于将他们知道的有关这个变量的所有信息都塞到命名里。要记住，命名只是一个标识符：只是告诉你该变量是在哪定义的。并不是用来告诉阅读者所有他们想知道的有关这个对象的详细信息。这是定义应该做的事情的。 命名只是让你找到它的定义。当我看到一个叫recentlyUpdatedAnnualSalesBid(最近更新的全年销售投标)的标识符时，我会问：
- 存在不是最近更新的全年销售投标么？
- 存在没有被更新的最近的全年销售投标么？
- 存在最近更新的非全年的销售投标么？
- 存在最近更新的全年非销售的投标么？
- 存在最近更新的全年销售非投标的东东吗？
上面任何一个问题的回答是“不存在”，就意味着命名中引入了无用的单词。
// 不好的:
finalBattleMostDangerousBossMonster;
weaklingFirstEncounterMonster;
// 改进:
boss;
firstMonster;
4 省略命名中可以从上下文获取的单词
类中的方法/属性和方法中的变量，都是存在在上下文中的，无需重复。
// Bad:
class AnnualHolidaySale {
int _annualSaleRebate;
void promoteHolidaySale() { ... }
}
// Better:
class AnnualHolidaySale {
int _rebate;
void promote() { ... }
}
5 省略命名中无任何含义的单词
在许多游戏开发中看到包含无任何含义的单词的命名，一些开发者喜欢在命名中添加一些看起来有点严肃的单词。我猜可能他们觉得这样做可以让他们的代码显得重要，或者说让他们觉得自己更重要。
实际上，有一些词语并没有实际意义，只是一些套话。比如：data, state, amount, value, manager, engine, object, entity和instance。
一个好的命名能够在阅读者的脑海中描画出一幅图画。而将某变量命名为”manager”并不能向读者传达任何有关该变量是做什么的信息。它是用来做绩效评估的吗? 它是管理加薪的吗?
在命名时可以问一下自己，把这个单词去掉含义是不是不变？如果是，那就果断把它剔除吧~~
// 不好的：
class DeliciousBelgianWaffleObject {
void garnishDeliciousBelgianWaffleWithStrawberryList(
List<Strawberry> strawberryList) { ... }
}
// 改进：
class Waffle { void garnish(List<Strawberry> strawberries) { ... } }
————————————————————————————分割线————————————————————————————————
感觉变量或者方法的命名，看似简单，实际很难，特别是想一个简洁明了、可读性高的命名。自己也经常用什么data, xxxlist来命名，作者说的挺对的，前者没什么意义，后者又有点啰嗦。不过对于集合类型的变量，统一用名词复数命名容易混淆。举个例子对于Apple这个类来说，可能存在List和Map两种集合类型的变量。个人觉得对List类型的变量可以采用名词复数来命名，Map类型的变量可以采用valueByKey格式来命名，比较容易区分。
作者: Bob Nystrom
