编码之道：取个好名字很重要（转）

代码就是程序员的孩子，给“孩子”取个好听的名字很重要！

　　我们在项目开发中，接触到的变量、函数、类多数都是项目自己定义的，往往都是为了解决一些特定的领域的问题，引入了各种各样的概念，代码里面的名字就对应着问题领域或方案领域的这些概念。所以，对于一个命名良好、代码规范、设计简洁的系统，要想非常快的理解一个系统，最直接的方式就是RTFC(Read The Fucking Code)。对于一个不断演进的系统，代码的可读性至关重要，首要要解决的问题就是名字，变量名、函数名、类名等都需要仔细斟酌，认真对待，一个能够简洁，能够清晰表达概念和意图的名字就显得尤为重要。

　　阅读《代码整洁之道》这本书后发现其中说的内容在我们自己项目中比比皆是，随便拿出一块代码都可以当做反面教材给大家讲半天。长时间积累，导致代码发霉变质，取名也是毫无章法，信手拈来。阅读这样的代码，撞南墙的心都有了。下面结合自己项目中的问题和《代码整洁之道》谈谈关于命名相关的原则。

　　1. 原则：名副其实

• 选名字是件严肃的事情，选个好名字很重要。
• 如果名字需要注释来补充，那就不是个好名字。
• 最重要的是要名副其实，名字能表达出概念和意图。

　　BAD:

int t = currentTime.elapse(e); // 消逝的时间,以毫秒计
...
if (t > timeout_value)
{
   Zebra::logger->debug("---一次循环用时 %u 毫秒-----", t);
}

GOOD:

int elapsed_ms = currentTime.elapse(e);
...
if (elapsed_ms > timeout_value)
{
   Zebra::logger->debug("-----一次循环用时 %u 毫秒---", elapsed_ms);
}

2. 原则：避免误导

• 必须避免留下掩藏代码本意的错误线索
• 避免使用与本意相悖的词
• 提防使用不同之处较小的名称
• 拼写前后不一致就是误导

　　BAD:

std::vector<int> account_list; // _list就是一个误导, accounts会更好
bool sendToZoneServer(); // 和下面的函数差别很小
bool sendToZoneServers(); // sendToAllZoneServers会好点

　　3. 原则：做有意义的区分

• 代码是写给人看的，仅仅是满足编译器的要求，就会引起混乱。
• 以数字系列命名(a1,a2,...)，纯属误导。
• 无意义的废话: a, an, the, Info, Data

　　BAD:

void copy(char a1[], char a2[]) {
  for (size_t i = 0; a1[i] != '\0'; i++)
     a2[i] = a1[i];
}

　　GOOD:

void copy(char source[], char dest[]) {
  for (size_t i = 0; source[i] != '\0'; i++)
     dest[i] = source[i];
}

　　4. 原则：使用可读的名字

• 避免过度使用缩写
• 可读的名字交流方便

　　猜一猜下面的类是干什么的？和别人怎么说这几个类？

　　根据这些简直变态的缩写，如果没有注释基本上很难知道是干什么的，当你和别人交流的时候，你就不得不一个一个字母来念“X-L-Q-Y”、“L-T-Q Manager”，鬼知道你说的是什么？PS. XLQY-XianLvQiYuan（仙履奇缘）, LTQ-LiaoTianQun（聊天群），有这样的名字也是醉了。

　　BAD:

class XLQY;
class FCNV;
class LTQManager;

　　5. 原则：使用可搜索的名字

• 避免使用Magic Number
• 避免使用单字母，或出现频率极高的短字母组合(注意度的把握)。

　　BAD:

if (obj->base->id == 4661) // 4661是啥玩意?
{
   usetype = Cmd::XXXXXXX;
}
int e; // 怎么查找?
XXXX:iterator it; // 变量作用的范围比较大的时候,也不见得是个好名字

　　GOOD:

#define OJBECT_FEEDBACK_CARD 4661
if (OJBECT_FEEDBACK_CARD == obj->base->id)
{
   usetype = Cmd::XXXXXXX;
}

　　6. 原则：名字尽量来自解决方案领域或问题领域

• 使用解决方案领域名称

　　写代码的同学多数都是都出自CS，术语、算法名、模式名、数学术语尽管用。如AccountVisitor：Visitor模式实现的Account类。

• 使用问题领域的名称

　　我们代码里面多数都是这些名称，不明白找策划问问，基本上都是功能相关的名称。

　　7. 原则：适当使用有意义的语境

• 良好命名的类、函数、名称空间来放置名称，给读者提供语境。
• 只有两三个变量，给名称前加前缀。
• 事不过三，变量超过三个考虑封装成概念，添加struct或class。

　　BAD:

// 看着整齐?使用方便?
DWORD love_ensure_type_;  //当前的爱情保险类型
DWORD love_ensure_ret_; //购买爱情保险回应标示
DWORD love_ensure_total_; //现在已经盖章数目
DWORD love_ensure_..._;  //...
DWORD love_ensure_..._;  //...

　　最后：我们的C++命名规范

• 文件名：
  • 首字母大写，多个词组合起来
  • 如: SceneUser.h, Sept.h
• 类名/名称空间名：
  • 首字母大写，多个词组合起来
  • 使用名词或名词词组
  • 避免使用C前缀，如: CSept
  • 如: SceneUser, SeptWar
• 函数名：
  • 首字母小写
  • 使用动词或动词词组
  • 避免使用孤立的全局函数,可以封装在类或名称空间里面
  • get, set, is前缀的使用
  • 如: fuckYou(), levelup()
• 变量名：
  • 全部字母小写，多个词以下划线分隔。
  • 私有成员变量加后缀_，公有变量不用。
  • 避免使用孤立的全局变量，可以封装在类或名称空间里面。
  • 如: quest_id, questid_

　　取名是一件严肃的事情，我们需要认真对待，名字代表着一个个概念，名字代表着你想表达的意图，好名字是可读代码的首要条件：

• 写下任何一行代码的时候，心里都要想着自己的代码是给别人看的。
• 为函数、变量、类取个好名字，遵循规范和原则。
• 见到不符合规范和原则的名字，确毫不留情的干掉它，特别是功能性的代码。

http://kb.cnblogs.com/page/517741/