边界测试??让BUG现形

　　运行结果：

　　input a line:            
　　I am a student.          
　　The longest word is : student

　　题目要求“写一个函数，输入一行字符，将此字符串中长的单词输出”，可是无论alphabetic()还是longest()函数都没有实现“输入一行字符，将此字符串中长的单词输出”这个功能要求。疑惑很久，发现实现这个功能的函数居然是main()。这难免让人贻笑大方了。因为按照常规的惯例，要求写一个函数实现某个功能，从来不是要求写main()，尽管不能说main()不是“一个函数”。然而如果是要求main()完成的事情，通常是作为一个完整的问题提出的，不会提出“写一个函数”这样的要求。如果硬要狡辩“写一个函数”也不排除是写main()，牵强的近乎强词夺理了。不过设若真的有人如此嘴硬，你还真拿他没什么办法。

　　既然是不见棺材不掉泪，那不妨继续往下看。

　　在代码中一眼瞄见了flag这个变量。经验表明，凡是有这个flag变量的代码，80%以上都是垃圾代码。道理很简单：首先，多数问题根本不需要设置这个别别扭扭标志变量，只有那些善于把自己的思维扭曲得如同烂麻花一样的人才喜欢时不时地祭出flag这个破烂的法宝。其次，即使需要设置标准变量，的代码作者也不会使用这个含义模糊不清的名字作为标志变量名，而会用一个更贴切、意义更明确恰当更适合描述问题的名字。所以，一般来说，flag往往反映了代码的垃圾度。

　　对于垃圾代码，没必要进行过于细致的分析，只要指出错误即可。不要试图了解这种代码的思路，因为这种代码的思路本来是错乱不堪的，如同不要试图理解疯子的胡言乱语一样。不要试图修缮一座胡乱搭建起来的破烂不堪的危房，推倒重来才是明智的选择。

　　然而，找出程序的漏洞或错误，往往比完成程序要难得多。而且越是垃圾的代码越难查错，因为垃圾代码往往也不具备良好的可测试性。

　　但是对付这种可测试性极差的垃圾代码，有一些简单的办法往往非常容易奏效，比如边界检查。训练有素的程序员通常都特别注意边界，无论是写代码时还是检查代码时。因为他们知道这里非常容易出错，而且往往失之毫厘谬之千里。但垃圾代码的作者，由于代码是东拼西补、胡乱拼凑而成的，所以往往顾不上或考虑不到这些，因此垃圾代码很容易被“边界检查”这把小刀轻而易举地戳破。以alphabetic()函数为例，只要简单地考察一下其中if语句所要求的表达式??(c>=‘a‘&&c<=‘z‘)||(c>=‘A‘&&c<=‘z‘)，不难发现c<=‘z‘这个子表达式是c<=‘Z‘之误。这样充分说明原代码中存在着BUG。

　　顺便说一下，alphabetic()函数中的if-else语句用得非常愚蠢，因为(c>=‘a‘&&c<=‘z‘) || (c>=‘A‘&&c<=‘Z‘)这个表达式的值本身只能为0或1，所以直接返回这个表达式的值可以了。压根用不着脱裤子放屁地写一个if-else语句。

int alphabetic(char c) 

{ 

   return   (c>=‘a‘&&c<=‘z‘)  

        ||  (c>=‘A‘&&c<=‘Z‘); 

}