论好的编程习惯与机制对减少人为错误的重要性——由拼接SQL语句小bug想到

一点点小教训，主要想谈论一下习惯问题。

很多企业有复杂的生产流程，反应到软件企业包括代码走查与各种测试流程，多到让人烦的不行，其实，这也是企业抵御风险，避免人为错误的机制。这种思维其实对于个人也很重要，我们个人开发写程序其实也很需要机制来抵御风险。

最近任务重，频繁变需求，频繁改动，加上服务器需要和网管、终端、测试等等同时交互，同时又要记着各种业务流程、又要改代码，又要应付各班人马，脑（lao）子内存都要爆了，这种时候一些小细节是记不住的。而恰恰现在的这个SQL语句拼接方式，有个小细节要记住，这个模式每次在后边新增一个字段，也就是复制结尾句，经常忘了给倒数第二句（原来的倒数第一句）加逗号。（也怪我懒，延续了前人的一种拼接模式。）

因为SQL语句最后一个字段要求没逗号的，所以这个SQL语句执行就错了（其实也该吐槽SQL语句的这种弱兼容性，也许人家出于好意只是提醒你是不是逗号后边忘写东西了吧～）。

		/* 3、构造SQL语句，执行更新操作 */
		memset(szSQL, 0, sizeof(szSQL));
		strcpy(szSQL, "UPDATE T_DDS_STATION_INFO set szIndex = ");
		sprintf(szBuf, "'%s', ", ptStationInfo->szIndex);
		strcat(szSQL, szBuf);

		//车站索引
		memset(szBuf, 0, sizeof(szBuf));
		sprintf(szBuf, "szIndex = '%s',", ptStationInfo->szIndex);
		strcat(szSQL, szBuf);

		/* 号码 */
		memset(szBuf, 0, sizeof(szBuf));
		sprintf(szBuf, "szStationNumber = '%s'", ptStationInfo->szStationNumber);
		strcat(szSQL, szBuf);
		

		/* 添加条件 限制*/
		memset(szBuf, 0, sizeof(szBuf));
		sprintf(szBuf, " where szIndex = '%s'", ptStationInfo->szIndex);//更新主键为索引
		strcat(szSQL, szBuf);

那么这种错误太频繁了，怎么办，改改吧，改成了下边这样。

		/* 3、构造SQL语句，执行更新操作 */
		memset(szSQL, 0, sizeof(szSQL));
		strcpy(szSQL, "UPDATE T_DDS_STATION_INFO set szIndex = ");
		sprintf(szBuf, "'%s' ", ptStationInfo->szIndex);
		strcat(szSQL, szBuf);

		//车站索引
		memset(szBuf, 0, sizeof(szBuf));
		sprintf(szBuf, ",szIndex = '%s'", ptStationInfo->szIndex);
		strcat(szSQL, szBuf);

		/* 号码 */
		memset(szBuf, 0, sizeof(szBuf));
		sprintf(szBuf, ",szStationNumber = '%s'", ptStationInfo->szStationNumber);
		strcat(szSQL, szBuf);
		

		/* 添加条件 限制*/
		memset(szBuf, 0, sizeof(szBuf));
		sprintf(szBuf, " where szIndex = '%s'", ptStationInfo->szIndex);//更新主键为索引
		strcat(szSQL, szBuf);

每一句都把逗号换前边，一直到前边，这个变动总得有个开始。

那么，反正都要折腾，有什么区别？其实这应该是个原则与习惯问题，前边的交界处，只要改一次就完了，怎么复制都不可能错误，以后再无隐患；而后边交界处（临界点）因为有那么一点点不一样，每次都要变动，如果你同时又想很多事情，其实是不台可能去管这种小细节的，这时候就会出错。避免这种人为错误的关键就是找到一个机制。

这就和if（1 == a）和if(a == 1)是一个道理，后者经常写成if(a =1)而导致错误很难被察觉，而前者出这种错是不可能编译通过的。

现实中，很多时候，因公因私，都可能心里装着别的东西而心思不在语法上，犯些小错误是很常见的，正所谓孰能无措。

最后，如果在一个大工程里老有这种错误发生，日志最好打的更细一点，免得找来找去浪费时间。