浅谈编码规范

今天我想谈一下我个人对编码规范方面的一些认知。在写这篇文章之前，我先给出两个词的定义，这两个词是作者看的某书上说的，个人也是非常认同。

一是编程老手：能长期写出稳定的高质量程序的程序员称为编程老手；

二是编程高手：能长期写出稳定的高难度，高质量程序的程序员称为编程高手；

好了，废话不多说，开始正篇讲解。首先，我想说的是大家都可能遇见过的一个现象，就是大家平时在公司做项目，或者自己私下自己做项目也好；都会发现代码越往后写，越觉得乱七八糟。然后和同事之间各种互相吐槽，撕逼。。。反正，就是一堆甩锅，就是自己不背锅。本人有几次也是，哈哈。但重要的是发现问题之后，及时解决就行。在这里，我用两个我自己的经历阶段对编码规范进行总结。

一是，本人在读大学的阶段。大一那会，大家都刚接触编程的时候。不会去管乱七八糟的规范(比如命名啊，代码注释，空格，换行等等)，只要程序能运行就行。老师教的也是如此(教本人的老师是这样的)，所以谈不上任何规范。让我有大幅度对编码规范认识的是在大三做的一个RPG游戏项目（C++编写，Win32，一个demo而已），我记得我重写过三次。当时是因为我回看自己写的代码是总觉得类封装的不行，但是又不知道怎么改更好，所以来回折腾了三次，还是不是很满意。这个项目中，现在来看当时已经对变量名，函数名，格式有了基本了解，但是，收获最大的是初步形成了代码review习惯（这个很重要）；

二是，本人踏入社会，在公司上班的阶段。记得当时是做的是一个游戏项目，恰好本人是核心部分（其实基本都是逻辑，就是有几个控件编写很麻烦），这个项目本人参与了全过程的开发。之后，项目组又陆续来了三个程序员，都是有多年经验的，但是结果让我感到诧异的是，他们写的代码质量很难（也许你会觉得这个词用得比较狠）。比如：tab键不是不对齐，if/for语句之间不加空格，过程化编程(拜托，大家都是学C++，能不能有点封装理念)，变量命名瞎命，没有注释等等。还有一些细节的，比如：上帝类管理，冗余类，野指针等等。我当时只想说这哪门子有经验的程序员，这是本人踏入社会的目前为止唯一一个完整的项目经验（结果没想到是这样的经历）。想着打算向前辈们学些东西（编码规范，设计模式什么的），结果是这样的；但也不全是坏处，比如了解了一个项目的完整流程，以及公司的框架结构设计等等。

从上述两个阶段，大家可能觉得和编码规范联系不大，但是没关系，上述两个阶段只是于本人而言是本人对编码规范认知的巨大转折点。如果写出有质量的程序员请继续往下看：

什么是编码规范？

变量命名规则，不一定要求必须是匈牙利，驼峰等等命名法则，但是得保证命名有意义，项目一致性或者个人一致性(就是当项目有多个人参与开发的时候，每个都有自己的命名习惯，而且不一致，这时你得保证自己的命名一致。其实这样实不好的，最好的方式就是项目全员都一致)

//类
class A {
private:
int m_nAge;
string m_strName;
}

函数名命名规则，根据不同的权限，可以采用多种命名方式融合。让人一眼就知道

class A {
//比如私有，驼峰法则
private:
void func1();

//比如公有，Windows法则
public:
void Func2();
}

代码格式，适当加入空格，换行可以让代码变得优雅。

//for循环
for (int i = 0; i < 1; i++) {
}
//if条件
if (true) {
}
else {
}

等等有很多规则，这里不一一例举，大家可以去到网上查查相关的资料。如果想规范自己写的程序，建议看《高质量C++》一书。

什么是规范写法？

其实这部分也可以算做是规范编码里的。本人觉得，这些很有必要单独说一下，因为在实际项目开发中可能会减少很多bug。

if条件零判断：

//bool变量判断(直接判断)
bool isValue = false;
if (isValue) {
}
//字符串和整形判断(等号判断)
int nValue = 0;
if (0 == nValue) {
}
//浮点数判断(大于，小于判断)
float fValue = 0;
if (fValue > -0.000001 && fValue < 0.000001) {
}

判断变量和常值是否相等时，将常值写在左边，避免误写成赋值语句而出现非语法错误。

int nValue = 1;
if (1 == nValue) {
}

变量初始化，以及避免野指针（不用的指针及时赋空）

class A {
private:
    int m_nValue;
    int *m_ptValue;
public:
    A()
    {
        this->m_nValue = 0;
        this->m_ptValue = nullptr;
    }
}

重载赋值运算，重新拷贝构造。

class A {
private:
    int* m_ptValue;
public:
    A& operator =(const A& obj);
    A(const A& obj);
}
A* a = new A();
B b = *a;
//如果没有重上述两个函数，上述代码中的m_ptValue会指向同一个地址，也就是说a被释放时，这时b中的m_ptValue就是也指针了。

常用this用于区分普通函数、临时变量、形参变量

class A {
private:
    int m_nValue;
public:
    void SetValue(int value)
    {
        this->m_nValue = m_nValue;
    }
}

等等有很多规则，这里不一一例举，大家可以去到网上查查相关的资料。如果想规范自己写的程序，建议看《高质量C++》一书。

如何坚持良好的习惯？

这些编码规则，我想任何的一本编程语言书上都会多多少少说一点吧。但是我们都会渐渐的忽视掉。下面的要求，志同道合的同志可以采取以下，真的很有必要。

●实战项目中，如果你自己发现不合理的地方，尤其是风格，写法完全不统一时，你得向你的主程提出建议进行修改；如果他觉得无所谓，这你也没办法，但是你得自己让你的风格和写法完全一致。比如：项目开发一半之后你发现你之前的命名不是很好，你想换一种风格命名是可以的，但是必须也要讲之前老的进行修改；

●实战项目中，发现什么规模不大可以优化的代码，及时调整修改或者重写，不要等以后，或者后期在做，因为没有后期（再说后期也有后期的事），本人是亲身经历过；

●实战项目中，期间可能你会看见很多同事乱七八糟的写法，或者会听到诸如此类的话语（公司项目就这样，你完成就行了；不要太执着，能方便就方便；等等），你必须约束你自己，不要被他们同化，因为进入社会了，大部分时间基本上都是在公司了，所以在公司的编程习惯就是你私下自己编程的习惯；

●实战项目中，尽量少出现特殊处理过程（考虑到项目周期可能十分紧凑可以采用），因为多一个特殊处理过程，后期维护多一分复杂；

●实战项目中，必须每隔一段时间回看自己写的代码，如果发现不合理，及时修改。这点是重中之重，这样能解决很多问题；

●实战项目中，有时间，多看看代码设计的书籍，对代码规范以及封装都有很大的帮助。

本人相信：优秀的程序员，代码一定规范（我的上任领导）；代码规范的程序员，不一定优秀（但一定在优秀的道路上）；说代码规范不重要的程序员，一定不优秀（我称之为搬砖员）。

最后，本人想说的是。上述说的这些，本人也并非全做到，之所以写出来，是因为有和本人一样的人，以及有想这样做的人但不知道从哪做起的人可能需要。如果写的代码bug太多，说明你仍需努力。强烈推荐《高质量C++》一书，真不错。主攻别的编程语言的程序员也可以看得，因为都是规范问题，有很多是可以借鉴的。很晚了，不写了，下篇见。