【樣本】
【評析】
單詞在文件中時不數，讀入內存后不數，擦掉標點后不數，切分之后還不數，居然還要把單詞“保存下來”，而且要保存在鏈表中。
通俗一點來說就是，不會數文章中的單詞的數目，需要先背下來；背下來之后還不行，還要把標點忘掉；忘掉之后還不行，還要把單詞一個個地“切分”出來；切分之后還不行，還要找個單詞本一個個地記錄下來。普通本子是不行滴，必須是一頁只能記錄一個單詞的本子，還必須只從前往后翻，
需要何等“清晰的編程頭腦”才能產生如此奇葩、雷人的構想啊？！
代碼部分，30是想當然的MagicNumber;_word以"_"開頭，違背C語言業界常規。實際上以“_”開頭的標識符是某些C++er命名成員變量的一種作風，在C語言中這樣寫是對C語言的一種污染。在C代碼中這樣寫有一定的風險。
【樣本】
【評析】
嗯。還需要把這種蹩腳的本子和文章貼在一塊。
所有的程序員都知道，需求變更是一件足矣讓人發狂的事件。因為以前的工作如果不是全部作廢，至少也是重創累累，完好的設計、代碼一下子變得到處都是毛病。
在這里，並不存在需求變更。而是邊寫代碼邊改設計（擴展txtfile結構體）。這一般有兩種可能：1.喜歡自虐；2.事先心中無數，像無頭蒼蠅一樣的寫代碼。寫不下去了，再臨時抱佛腳修改數據結構。這是一種顛三倒四的工作方法。
【樣本】
【評析】
嗯，單詞本的每一頁上還記錄單詞出現的次數。可是問題的要求是計算關鍵詞的詞頻，所以只需要求出關鍵詞出現的次數和單詞總數就足以完成要求。把所有的單詞出現的次數都計算出來，是嫌計算機計算太快還是腦子進水了？
【樣本】
【評析】
到底是MVP，敢於“邊設計，邊施工”，徹底顛覆軟件工程的基本原則。
在實際工作中，很多人出於種種無奈都干過類似的臟活。但敢於在書中公開這么寫就完全是另一回事了。
“不僅能得到各個單詞，還能得到各個單詞的個數以及文件中總的單詞數”。嗯，聰明,高效！為了解決飢餓問題，所以坐在馬桶上吃飯，不但把飯給吃了，還能順便把廁所給上了，盡管並不需要上廁所。
【樣本】
【評析】
小本子是一頁一頁貼出來的，每寫一頁，必須貼在本子的最后一頁后面。沒紙（malloc()調用返回NULL）了怎么辦？就裝模作樣地寫一頁（strcpy(node->text,text)）。至於寫到了哪里，有沒有貼到本子上他是不管的。
實際上認為“新添加的結點肯定是鏈表的尾結點”而把新結點加到鏈表的尾部只能說是一種不理智的偏執。因為這種做法除了給自己添麻煩之外沒有任何益處，也表明作者根本不懂如何使用鏈表。鏈表的優勢是在頭部加入結點或刪除結點，特別適合描述FILO。
【樣本】
【評析】
謝天謝地！這回總算沒采用“更加有效的查找算法——折半查找算法”，估計是上次使用了一回之后自己都對這種“更加有效的查找算法”心有余悸了吧。
node變量多余。