产品开发这几年（5）编码规范
真正的程序员将代码视为生命的结晶，从不浪费。然而，程序员并非天神，也会犯错，所以没有bug的代码永远不存在。为了打破宿命，程序员拼命修炼，似朝圣一般对代码精益求精。由于程序员性格各异，各自修炼法诀千差万别，单打独斗各有所长，但当共同面临强大的武林公敌时，即便有高手压阵，相互配合也显得捉襟见肘，更不用说打败强敌。鉴于此，大家便共同商讨出一个盟约以约束所有成员，保证力量的同向性，在临阵对敌时发挥最大威力，而这个盟约便是编码规范。
程序员的江湖从不平静，每个程序员从来都是独一无二的，但编码规范却试图约束层出不穷的高手遵循统一的规则，这是有悖于人性的。尽管如此，不可否认的是每每出现强大的武林败类时，遵循编码规范总能旗开得胜，而无视编码规范最终反被魔头炼化。在一次次血的教训下，所有程序员都意识到，遵守编码规范原来是程序员的基本修养之一！
从某种程度上来讲，编码规范是程序员的天敌，而且编码规范从来都是软件开发中最混乱最具争议的焦点之一，不同公司甚至同一公司不同产品或项目都有各自的编码规范，有些规范甚至是相悖的。但是，要融入到一个团队中，便必须接受团队的规范，如果有合理的建议再不断改进。
本文并试图阐述冗长且各异的编码规范，仅针对其中几点分享个人一点经验。然而，在此之前，推荐两本在软件开发中广泛流传的编码规范：
《GoogleC++ Style Guide》
《高质量程序设计指南——C++/C语言》
其中，《GoogleC++ Style Guide》号称全世界最优秀的编码规范，确实可圈可点，但并不能一概而论，事实上很多企业并未采用。《高质量程序设计指南——C++/C语言》可能是很多程序员最先见到的编码规范类资料了，其中诸多见解影响了很多程序员的一生。
1、 代码注释
代码注释是最简单的规范，但却是最混论的规范。本文并不试图说教，但以下几点在软件开发中却值得关注。
1) 注释风格
很多使用过VC等IDE环境的程序员很喜欢使用“//”注释代码，而不少从事低层C语言开发的程序员则习惯使用“/*……*/”注释代码，这两种风格在当前C/C++开发中都是允许的，所谓萝卜白菜各有所爱。然而，一般情况下，建议单行注释使用“//”，而多行注释使用“/*……*/”，如下所示。
/*
本函数涉及TDM路由分配，未经允许严禁改动！！
如要改动，请遵循如下原则：
1.
2.
*/
bool TdmManage(TdmRoute &Route)
{
......
}
// 打印显示所有TDM路由
bool ShowTdmRoutes(void)
{
......
}尽管上述两种注释方式都是可行的，但并非通用的，有的编译器只支持“/*……*/”注释风格，例如鼎鼎大名的Tornado。
2) 中英文注释
中英文注释同样是令程序员纠结异常的一个问题。其实大部分程序员都倾向于中文注释，毕竟是自己熟悉的母语，可以十分清楚地阐述代码意义，而英文则注释起来十分蹩脚。事实上，很多编码规范都建议优先使用中文注释，即“中文注释为主，英文注释为辅”。
和注释风格类似，中文注释有时候是灾难性的，英文注释变成了唯一选择。例如，在我所经历的的一个产品中，开始在Windows上使用Source Insight编辑的中文注释，将代码移植到Ubuntu上的Eclipse后完全乱码，不得不强制项目组使用英文注释，且还需要将之前的中文注释及时更正，无疑增加了极大的工作量。
关于中英文注释，最后一点要强调的便是坚决抵制汉语拼音注释！个人固执地以为，拼音注释几乎是程序员的耻辱，但貌似有人却乐此不疲，我甚至见到某个模块的代码全部使用拼音注释，让我不禁怀疑该“程序员”注释的初衷及人品！
3) 注释百分比
代码是写给程序员读的，同样是要交由程序员维护的，因此必要的注释不可或缺，尤其对于产品维护更是如此。实际产品开发中，随着需求的不断推进，很多时候注释是理解设计意图的唯一指引，因此很多编码规范都要求注释百分比不低于一定数值。然而，此规范执行起来是有难度的，因为注释并不能随意添加，所谓“必要的注释”尺度很难把握，只能取决于程序员的个人理解。需要强调的一点是，注释并非越多越全便好，毕竟代码不是文档。一般情况下，要求代码注释百分比不低于20%~30%。
与注释百分比针锋相对的是，很多武林高手认为“优秀的代码都是自注释的”。确实，通过良好的命名规范、设计模式、程序逻辑等的确可以使得代码本身便阐述了其意图，但问题在于这样优秀的代码有多少，或者说如此优秀的程序员有多少呢？因此，个人以为注释仍是当前程序设计中不可或缺的重要组成，但程序员良好的修养可极大提高代码自注释水准，从而减少人为注释。
4) 注释更新
程序员们一定听说过代码腐烂或代码膨胀等，注释同样存在类似问题。很多时候产品开发并非一蹴而就，其开发维护周期极长，尤其大规模商用的版本，其中产品代码可能要经历很多程序员的蹂躏。大多程序员都是慵懒的，或者更关注产品功能特性的，因此对注释的维护更新可能不太关注。久而久之，后面的程序员不敢随意删除前辈们的注释，而代码又不断变更，导致很多注释与代码不符，甚至是错误的。
注释腐烂是滚雪球式的，到后面可能无法控制，因此优秀的程序员一定会及时更新自己所变更代码的注释，这是程序员基本的修养之一。
2、 命名规范
注释可能是最混乱的规范，但命名则是最困难的规范。程序开发中的命名好似给小孩起名，每个程序员都希望起个好名字，但执行起来却异常困难，给小孩有过命名经历的人一定深有体会。鉴于此，命名规范希望借助统一的规则，最大限度地约束程序员命名方式，从而保证代码风格一致。
命名规则中最鼎鼎大名且影响广泛的当属“匈牙利命名”，几乎每一位程序员都深受其影响。在微软诸如MFC等产品中，匈牙利命名的例子随处可见。然而悲哀的是，目前为止没有一种命名规则是被所有程序员认可的，因为其总有缺陷。这便是程序员的通病，总是高不成低不就！尽管如此，个人以为匈牙利命名仍是十分优秀的命名规则，事实上很多公司均采用其作为规范。
匈牙利命名规则并非本文讨论的重点，本文想要强调的是，无论采用何种命名规范，在实际代码开发过程中应该自始至终地贯彻执行，从而保持代码整体风格一致！
3、 代码格式
代码格式本无需讨论，但鉴于程序员对代码的第一印象取决于代码格式，本文对此仍进行简单讨论。
1) 空格
个人以为，代码外观核心因素取决于空格。空格包括语句内空格及与语句前空格，对于如何使用空格，本文不做深究，但如下代码深刻展示了空格的巨大魅力。事实胜于雄辩，无需多言。
// 无空格
for (int j=(int)second.size()-1;j>=0;j--)
{
unsigned char mid=(first[i]-'0')*(second[j]-'0')+flag;
if(mid>9)
{
flag=mid/10;
mid =mid%10;
}
else
{
flag=0;
}
}
// 有空格
for (int j=(int)second.size()-1; j>=0; j--)
{
unsigned char mid = (first[i] - '0') * (second[j] - '0') + flag;
if (mid > 9)
{
flag = mid / 10;
mid = mid % 10;
}
else
{
flag = 0;
}
}2) 空行
尽管空行同样会影响代码外观，但其更多的作用在代码逻辑分割上。如下代码中，尽管有无空行对程序功能毫无影响，但添加空行分割后，程序员的逻辑意图便可清晰展现出来。
// 无空行
int sortbyrule(int digits[], char *pstrInput, char *pstrOutput)
{
if (NULL==pstrInput || NULL==pstrOutput)
{
return -1;
}
for (int i=0; i本文对编码规范的讨论到此为止。实际上，编码规范的内容很广泛，本文仅对程序员们最常见的几点进行了讨论，其余内容便望而生却了，毕竟实在太过繁杂。