好的编程习惯是减少bug最有效的方法

公司来了几个新手，有时候很简单的一个功能模块都要耗费好几天时间，总是在一些不相关的问题上死耗一整天，搞出莫名其妙的问题，找不到具体原因，总是怀疑编译出问题了，系统出问题了，板子出问题了，搞到快下班了叫我帮他们看看。

我总跟他们说，不要轻易怀疑系统，先去检查自己的“所作所为“，虽然系统也会有出错的时候，但是你永远要相信你自己出错的概率远大于系统，99.9%的时候都是你自己出了问题。

首先，静态检查自己所写的每一行代码是有必要的，虽然有时候编译通过并不代表程序没有问题，只能说明语法上通过了，但是是否真实按照自己的设计意图编写的，却很难说。

编程习惯不好，很容易在匆忙大意的时候改变了程序的设计逻辑，但是编译却能正常通过，自己却还不知不觉。

举两个编程习惯的例子供参考。

一、运算符与字符之间最好保留空格。

如下对比

int a=2;
int b=3;

int c = 4;
int d = 5;

　可以明显看的出来，后面两行会更加舒适美观，但这不是我要说的重点，重点时候有时候这可以规避一些问题。

再看下面的代码块

/* no space */
int comp_var(int *b)
{
　　int a=4;

　　if (NULL==b)
　　　　return a;
　　else
　　　　return a/*b;
}

　　

上面这部分代码编译时无法通过，设计者原本意图是想计算a 除以 b指针的值，但是/*b 会被编译器解析成/* 表示注释开始，b属于注释内容，还会一直寻找最后的*/注释结束符。

加上空格之后就消除了这种歧义。

/* with space */
int comp_var(int *b)
{
　　int a = 4;

　　if(NULL == b) {
　　　　return a;
　　} else {
　　　　return a / *b;
　　}
}

　　

二、变量与常量进行==比较时，最好把常量写前面，变量写后面。

这种做法在一不小心将==写成了=号时，编译器能及时发现错误并告知我们，否则，编译器直接编译通过，但是当你运行程序的时候结果总是带给你“惊喜”。

int comp_var(int a)
{
　　int b = 4;

　　/* if(a == 3） */
　　if(a = 3)
　　　　return b;
　　else
　　　　return a;   
}

　　

程序设计者本意是想比较a 和 3是否相等，但是误写成了赋值，编译器能正常编译通过看，但是程序执行时 if 条件永真，永远返回b的值4。

如果将常量写在前面，则编译器在编译时便会报错提醒，开发者可以随时纠正。

int comp_var(int a)
{
　　int b = 4;

　　/* if(3 == a) */
　　if(3 = a)
　　　　return b;
　　else
　　　　return a;    
}