实用经验 98 避免使用“聪明的技巧”

“聪明的技巧”最初有设计大师Dijkstra提出。在1972年的图灵颁奖礼上，他说过这么一段话“优秀的程序员很清楚自身的能力是有限的，所以他们对待任务也是谦卑的，特别是他们会避免那些像瘟疫一样的‘聪明的技巧’”。

聪明的技巧，一般指那些功能完备但不宜于理解的代码。如下面这段代码，你明白它的功能吗？

// 不用任何变量，交换两数。
int a,b; 
a = a^b; 
b = a^b 
a = a^b

你可以仔细分析一下，这段代码的功能确实是交换两个变量的值。但是对于大多数程序开发人员而言，理解这个实现确实不是很容易。我们看一个常见的经典实现：

//交换两数值
int a, b;

int c = a;
a = b;
b = c;

这段代码实现的功能和上一段完全一样。但是非常易于理解。和上一段相比之下它唯一个好的地方便是它引入了一个变量。但是从代码可读性而言，他优于上一段代码。

不仅如此，它之所以被称之为经典实现，还主要是即使他没有注释，我们也可以知道这段代码的意图。但是上一段代码就不同了。他不但不能自注释，而且还特别难以理解。

在实际编码过程中，还有不少这样的案例。

例如，某同学崇拜乱码大赛那种编码风格，为了显示自己编码技巧高超。于是便把这种风格引入到实际工程项目的开发中了。最终搞得同项目组的其他成员焦头烂额，最终导致项目没有按期完成。下面这段代码是Hello world乱码实现。

int n[]={0x48, 0x65,0x6C,0x6C, 0x6F,0x2C,0x20, 0x77,0x6F,0x72, 0x6C,0x64,0x21, 0x0A,0x00},*m=n; 
main(n){putchar (*m)!='\0'?main (m++):exit(n++);}

我们不能说这段代码存在什么问题？毕竟人家是编码大赛的得奖作品。但是我们不是编码大师，我们编写的代码是给同事或自己看得。我们在编写代码是易于理解，可读性强是最起码的要求。

请谨记

• “聪明的技巧”对“技巧”要求太高。一般程序员无法理解。也影响了代码的可读性和可维护性。所以，请最好避免使用这种“聪明的技巧”。