此前，我们已经描述过应当遵守的规范，这里我们再次强调和补充一些内容和讨论。

  代码规范，就是在代码编写过程中应当遵守的规范。在不同的公司中对代码规范有不同的要求，在个人开发中代码规范就完全看自己的喜好了。无论如何，代码规范在代码开发中都是非常重要的一项内容。

  对于项目开发，如果没有统一规范，在项目渡过前期甚至前期还没有渡过就会遇到各种各样的问题。维护困难、拓展困难等等等等。所以在项目开发中，都会对规范有明确的要求。

  不过在各种比赛中，因为绝大多数比赛只允许提交一个文件，按文件分类是一个不可能的事情。尤其是类似程序设计竞赛一类的比赛，代码长度通常不会超过150行，这时候代码规范就显得不是非常重要。

  曾经我跟老师提到过这方面的问题，但是老师认为竞赛代码追求简洁，越紧凑越好。这是母庸置疑的，但是这不代表代码规范对于竞赛代码一文不值，其中一部分我们仍然需要严格遵守。

  按照我曾经的经验，代码编写过程中，尤其是变量名的命名，一定要遵循规范。曾经我因为使用了w和h分别表示宽高，导致有一行代码两个变量名混淆，从而致使我排查了一个多小时的漏洞，最终还是学长发现了这个问题。

  这说明一个问题：就算代码只有几十行，不良的编写习惯仍然有可能给我们埋下一颗不定时的炸弹。

  再例如缩进，毫不客气地说，没有正确缩进的代码基本不具备可读性。从某些方面来说，不正确的缩进比错误的变量名更加致命，它可能让我们错误的解读代码的控制流，还有可能让我们漏掉一些关键的语句……

  还有之前提到的宏定义，在任何场景中，包括项目开发和竞赛代码，任何能够用其它语句替代的语句都不应当使用宏编写。因为宏定义（尤其是定义函数）是一件费力不讨好的事情。比如下面的代码：

1
2
3
4
5
6
#define mult(x, y) x * y

int main() {
    printf("%d", mult(5 + 6, 1 + 5));
    return 0;
}

  这段代码理想中的结果应该是66，但是实际上却输出了16。这就是宏定义的一个严重的“漏洞”，当调用宏定义的函数过程中使用i++一类的语句可能会导致更加严重的后果。

  同时因为宏是预处理语句，其在代码进入编译器前就完成了处理，所以编译器看不到任何宏。假如我们用宏定义了一个PI 3.1415926，但是在编译过程中如果出现了与宏相关的编译错误，编译器不会说PI发生了什么，而是会说3.1415926发生了什么。当代码量较大时排查错误会变得非常困难，因为你需要靠脑子想3.1415926可能在哪里定义的。

  再没有摸清楚宏的运作原理的情况下使用宏是一件非常危险的事情，如果真的必须使用宏那么一定要小心之上再小心，同时也要避免让宏的使用毁掉代码的可读性。

  程序员对规范的追求是无止境哒，祝各位在追求规范的道路上五风十雨。