垃圾“程式是怎樣練成的”——關於《C程式設計伴侶》第A章（三）

文章目錄

•  
•  
•  
•  
•  
•  

 

 

【樣本】

 

 

 【評析】

　　單詞在檔案中時不數，讀入記憶體後不數，擦掉標點後不數，切分之後還不數，居然還要把單詞“儲存下來”，而且要儲存在鏈表中。
　　通俗一點來說就是，不會數文章中的單詞的數目，需要先背下來；背下來之後還不行，還要把標點忘掉；忘掉之後還不行，還要把單詞一個個地“切分”出來；切分之後還不行，還要找個單詞本一個個地記錄下來。普通本子是不行滴，必須是一頁只能記錄一個單詞的本子，還必須只從前往後翻，
　　需要何等“清晰的編程頭腦”才能產生如此奇葩、雷人的構想啊？！
　　代碼部分，30是想當然的MagicNumber;_word以"_"開頭，違背C語言業界常規。實際上以“_”開頭的標識符是某些C++er命名成員變數的一種作風，在C語言中這樣寫是對C語言的一種汙染。在C代碼中這樣寫有一定的風險。

 

【樣本】

 

 

 【評析】

　　嗯。還需要把這種蹩腳的本子和文章貼在一塊。
　　所有的程式員都知道，需求變更是一件足矣讓人發狂的事件。因為以前的工作如果不是全部作廢，至少也是重創累累，完好的設計、代碼一下子變得到處都是毛病。
　　在這裡，並不存在需求變更。而是邊寫代碼邊改設計（擴充txtfile結構體）。這一般有兩種可能：1.喜歡自虐；2.事先心中無數，像無頭蒼蠅一樣的寫代碼。寫不下去了，再臨時抱佛腳修改資料結構。這是一種顛三倒四的工作方法。

 

【樣本】

 

 

 【評析】

　　嗯，單詞本的每一頁上還記錄單詞出現的次數。可是問題的要求是計算關鍵詞的詞頻，所以只需要求出關鍵詞出現的次數和單詞總數就足以完成要求。把所有的單詞出現的次數都計算出來，是嫌電腦計算太快還是腦子進水了？

 

【樣本】

 

 

 【評析】

　　到底是MVP，敢於“邊設計，邊施工”，徹底顛覆軟體工程的基本原則。
　　在實際工作中，很多人出於種種無奈都幹過類似的髒活。但敢於在書中公開這麼寫就完全是另一回事了。
　　“不僅能得到各個單詞，還能得到各個單詞的個數以及檔案中總的單詞數”。嗯，聰明,高效！為瞭解決饑餓問題，所以坐在馬桶上吃飯，不但把飯給吃了，還能順便把廁所給上了，儘管並不需要上廁所。

【樣本】

 

 

 【評析】

　　小本子是一頁一頁貼出來的，每寫一頁，必須貼在本子的最後一頁後面。沒紙（malloc()調用返回NULL）了怎麼辦？就裝模作樣地寫一頁（strcpy(node->text,text)）。至於寫到了哪裡，有沒有貼到本子上他是不管的。
　　實際上認為“新添加的結點肯定是鏈表的尾結點”而把新結點加到鏈表的尾部只能說是一種不理智的偏執。因為這種做法除了給自己添麻煩之外沒有任何益處，也表明作者根本不懂如何使用鏈表。鏈表的優勢是在頭部加入結點或刪除結點，特別適合描述FILO。

【樣本】

 

 

 【評析】

　　謝天謝地！這回總算沒採用“更加有效尋找演算法——折半尋找演算法”，估計是上次使用了一回之後自己都對這種“更加有效尋找演算法”心有餘悸了吧。
　　node變數多餘。