如何给变量取个简短且无歧义的名字
---恢复内容开始---
来自知识库http://kb.cnblogs.com/page/548394/
译/Giraffe
都是经验之谈，没什么道理可讲。
这篇文章通过举例子来使其易懂。值得学习。
UPD 2016年12月22日22:16:12: 深受启发。我的博客文章地址一个单词就够啦！
正文
命名中无需含有表示变量或参数类型的单词
即，不要用匈牙利命名法。
// 不好的:
String nameString;
DockableModelessWindow dockableModelessWindow;
// 改进:
String name;
DockableModelessWindow window;
集合用复数名词:
// 不好的:
List<DateTime> holidayDateList;
Map<Employee, Role> employeeRoleHashMap;
// 改进:
List<DateTime> holidays;
Map<Employee, Role> employeeRoles;
方法名不需要描述它的参数及参数的类型——参数列表已经说明了这些。
// 不好的:
mergeTableCells(List<TableCell> cells)
sortEventsUsingComparator(List<Event> events,
Comparator<Event> comparator)
// 改进:
merge(List<TableCell> cells)
sort(List<Event> events, Comparator<Event> comparator)
省略命名中不是用来消除歧义的单词
当我看到一个叫recentlyUpdatedAnnualSalesBid(最近更新的全年销售投标)的标识符时，我会问：
- 存在不是最近更新的全年销售投标么？
- 存在没有被更新的最近的全年销售投标么？
- 存在最近更新的非全年的销售投标么？
- 存在最近更新的全年非销售的投标么？
- 存在最近更新的全年销售非投标的东东吗？
上面任何一个问题的回答是“不存在”，就意味着命名中引入了无用的单词。
// 不好的:
finalBattleMostDangerousBossMonster;
weaklingFirstEncounterMonster;
// 改进:
boss;
firstMonster;
另外一种，自我指涉（望文生义）
// Bad:
class AnnualHolidaySale {
int _annualSaleRebate;
void promoteHolidaySale() { ... }
}
// Better:
class AnnualHolidaySale {
int _rebate;
void promote() { ... }
}
实际上，一个命名嵌套的层次越多, 它就有更多的相关的上下文，也就更简短。换句话说，一个变量的作用域越小，命名就越短。
我常常在许多游戏开发中看到包含无任何含义的单词的命名，一些开发者喜欢在命名中添加一些看起来有点严肃的单词。我猜可能他们觉得这样做可以让他们的代码显得重要，或者说让他们觉得自己更重要。
实际上，有一些词语并没有实际意义，只是一些套话。比如：data, state, amount, value, manager, engine, object, entity和instance。
一个好的命名能够在阅读者的脑海中描画出一幅图画。而将某变量命名为”manager”并不能向读者传达任何有关该变量是做什么的信息。它是用来做绩效评估的吗? 它是管理加薪的吗?
在命名时可以问一下自己，把这个单词去掉含义是不是不变？如果是，那就果断把它剔除吧~~
华夫饼的例子
// 好吃的比利时华夫饼
class DeliciousBelgianWaffleObject {
void garnishDeliciousBelgianWaffleWithStrawberryList(
List<Strawberry> strawberryList) { ... }
}
首先，通过参数列表我们可以知道方法是用来处理一个strawberry的列表，所以可以在方法命名中去掉：
class DeliciousBelgianWaffleObject {
void garnishDeliciousBelgianWaffle(
List<Strawberry> strawberries) { ... }
}
除非程序中还包含不好吃的比利时华夫饼或者其他国家的华夫饼（23333），不然我们可以将这些无用的形容词去掉：
class WaffleObject {
void garnishWaffle(List<Strawberry> strawberries) { ... }
}
方法是包含在WaffleObject类中的，所以方法名中无需Waffle的说明：
class WaffleObject {
void garnish(List<Strawberry> strawberries) { ... }
}
很明显它是一个对象，任何事物都是一个对象，这也就是传说中的“面向对象”的含义（23333333333333333333333333），所以命名中无需带有Object：
class Waffle {
void garnish(List<Strawberry> strawberries) { ... }
}
好了，这样看起来好多了。
以上就是我总结的相当简洁的命名原则。可能有些人会觉得无需在命名上耗费太多的精力，但我认为命名是开发过程中最基本的任务之一。
---恢复内容结束---
来自知识库http://kb.cnblogs.com/page/548394/
译/Giraffe
都是经验之谈，没什么道理可讲。
这篇文章通过举例子来使其易懂。值得学习。
正文
命名中无需含有表示变量或参数类型的单词
即，不要用匈牙利命名法。
// 不好的:
String nameString;
DockableModelessWindow dockableModelessWindow;
// 改进:
String name;
DockableModelessWindow window;
集合用复数名词:
// 不好的:
List<DateTime> holidayDateList;
Map<Employee, Role> employeeRoleHashMap;
// 改进:
List<DateTime> holidays;
Map<Employee, Role> employeeRoles;
方法名不需要描述它的参数及参数的类型——参数列表已经说明了这些。
// 不好的:
mergeTableCells(List<TableCell> cells)
sortEventsUsingComparator(List<Event> events,
Comparator<Event> comparator)
// 改进:
merge(List<TableCell> cells)
sort(List<Event> events, Comparator<Event> comparator)
省略命名中不是用来消除歧义的单词
当我看到一个叫recentlyUpdatedAnnualSalesBid(最近更新的全年销售投标)的标识符时，我会问：
- 存在不是最近更新的全年销售投标么？
- 存在没有被更新的最近的全年销售投标么？
- 存在最近更新的非全年的销售投标么？
- 存在最近更新的全年非销售的投标么？
- 存在最近更新的全年销售非投标的东东吗？
上面任何一个问题的回答是“不存在”，就意味着命名中引入了无用的单词。
// 不好的:
finalBattleMostDangerousBossMonster;
weaklingFirstEncounterMonster;
// 改进:
boss;
firstMonster;
另外一种，自我指涉（望文生义）
// Bad:
class AnnualHolidaySale {
int _annualSaleRebate;
void promoteHolidaySale() { ... }
}
// Better:
class AnnualHolidaySale {
int _rebate;
void promote() { ... }
}
实际上，一个命名嵌套的层次越多, 它就有更多的相关的上下文，也就更简短。换句话说，一个变量的作用域越小，命名就越短。
我常常在许多游戏开发中看到包含无任何含义的单词的命名，一些开发者喜欢在命名中添加一些看起来有点严肃的单词。我猜可能他们觉得这样做可以让他们的代码显得重要，或者说让他们觉得自己更重要。
实际上，有一些词语并没有实际意义，只是一些套话。比如：data, state, amount, value, manager, engine, object, entity和instance。
一个好的命名能够在阅读者的脑海中描画出一幅图画。而将某变量命名为”manager”并不能向读者传达任何有关该变量是做什么的信息。它是用来做绩效评估的吗? 它是管理加薪的吗?
在命名时可以问一下自己，把这个单词去掉含义是不是不变？如果是，那就果断把它剔除吧~~
华夫饼的例子
// 好吃的比利时华夫饼
class DeliciousBelgianWaffleObject {
void garnishDeliciousBelgianWaffleWithStrawberryList(
List<Strawberry> strawberryList) { ... }
}
首先，通过参数列表我们可以知道方法是用来处理一个strawberry的列表，所以可以在方法命名中去掉：
class DeliciousBelgianWaffleObject {
void garnishDeliciousBelgianWaffle(
List<Strawberry> strawberries) { ... }
}
除非程序中还包含不好吃的比利时华夫饼或者其他国家的华夫饼（23333），不然我们可以将这些无用的形容词去掉：
class WaffleObject {
void garnishWaffle(List<Strawberry> strawberries) { ... }
}
方法是包含在WaffleObject类中的，所以方法名中无需Waffle的说明：
class WaffleObject {
void garnish(List<Strawberry> strawberries) { ... }
}
很明显它是一个对象，任何事物都是一个对象，这也就是传说中的“面向对象”的含义（23333333333333333333333333），所以命名中无需带有Object：
class Waffle {
void garnish(List<Strawberry> strawberries) { ... }
}
好了，这样看起来好多了。
以上就是我总结的相当简洁的命名原则。可能有些人会觉得无需在命名上耗费太多的精力，但我认为命名是开发过程中最基本的任务之一。
