要求

1.????? 對源文件（*.txt,*.cpp,*.h,*.cs,*.html,*.js,*.java,*.py,*.php等）統計字符數、單詞數、行數、詞頻，統計結果以指定格式輸出到默認文件中，以及其他擴展功能，并能夠快速地處理多個文件。

2.????? 使用性能測試工具進行分析，找到性能的瓶頸并改進

3.????? 對代碼進行質量分析，消除所有警告

4.????? 設計10個測試樣例用于測試，確保程序正常運行（例如：空文件，只包含一個詞的文件，只有一行的文件，典型文件等等）

5.????? 使用Github進行代碼管理

6.????? 撰寫博客

基本功能

1.????? 統計文件的字符數

2.????? 統計文件的單詞總數

3.????? 統計文件的總行數

4.????? 統計文件中各單詞的出現次數

5.????? 對給定文件夾及其遞歸子文件夾下的所有文件進行統計

6.????? 統計兩個單詞（詞組）在一起的頻率，輸出頻率最高的前10個。

7.????? 在Linux系統下，進行性能分析，過程寫到blog中（附加題）

PSP：

?

前期的分析：

首先看到了題目就立刻想到了會有巨大的數據需要進行處理，自然就會聯想應該如何去解決數據的存放問題與查找問題，從功能需求中一步步想到了使用哈希表對此進行存儲，于是便有了初步的想法：

1、打開一個文件，讀取文件內容；

2、將讀取的信息進行處理；

3、構造一個哈希函數，創建一個哈希表。

之后有關測試文件出來了，便遇到了一個很棘手的問題：對于文件的遍歷，這個起初是打算用C語言中的fopen函數，但仔細一分析發現并不能實現具體的要求，于是便尋求一個可以遍歷文件的操作，在查閱資料后找到了C++語言中的findfirst和findnext函數可以實現文件操作，于是便開始對其的學習，由于之前未接觸過C++，對于其中過程的了解耗費了很長的時間，于是便對測試文件進行了初步的遍歷實驗，起初的結果很不近人意，只能遍歷文件的第一個子目錄里的文件，無法進入子文件夾，進過判定條件的修改，最終實現了所有文件的遍歷。 ??????

此刻第一步便達到了目的，于是開始了文件讀取問題的思考，找到了兩個函數，get和getline函數，首先get函數可以很好的讀取文件中的字符，依靠對文件是否結束的判定可以持續讀取，這個的好處就在于可以無所謂文件中全部的字符總量，可以一邊讀一邊根據判定條件進行對單詞與詞組的操作，并且可以按照換行符的數量判斷一個文件中的行數，這個可以說是很理想；其次是getline函數，它可以一次讀取一行，這個可以省去單獨統計換行符的工作，每次調用的時候就可以進行行數的累加，然后可以直接用一行一行的處理單詞與詞組，這個可以更加模塊化，但是缺點便是文件中會出現一行中有數十萬的字符，就會使得數組溢出導致失敗；經過考慮，我選擇了getline函數。

然后就是開始對這個項目進行框架的搭建，從字符、單詞到詞組，每一個都單獨進行搭建，互不相關，為了達到這個目的，分別為單詞與詞組設計了各自的哈希表，由于要同時對出現頻率的統計，決定構造一個結構體數組，里面存儲字符串與整型數據，而數組的地址則用設計的哈希函數進行計算。

代碼設計：

1、 文件遍歷

利用已經試驗過的findfirst與findnext函數進行操作；

2、 文件讀取

利用ifstream函數打開文件，再利用getline函數對文件內容進行讀取，在文件函數中直接調用字符的函數、單詞的函數、詞組的函數；

3、 字符統計

對傳入的字符數組，進行遍歷，并隨之進行數據的統計；

4、 單詞統計

對傳入的字符數組進行有條件的遍歷，篩選出符合條件的單詞，調用單詞的哈希表構造函數

（1）????? 單詞哈希表構造

消除大小寫的影響，即在計算哈希函數時使用單詞前四個字母時，全部化為小寫進行求解，利用平方取中法構造哈希函數，利用開放定址發解決沖突，其中需要調用單詞比較函數和單詞優先級比較函數；

1） ??單詞比較函數

比較新單詞與哈希表中同一位置單詞是否為相同單詞；

?2）單詞優先比較函數

比較兩個相同單詞在字典輸出的情況下的先后次序；

5、 詞組統計

對傳入的字符數組進行有條件的遍歷，篩選出符合條件的詞組，調用詞組的哈希表構造函數 ，其中判斷詞組需要大量的判定條件；

（1）????? 詞組哈希表構造

消除大小寫的影響，即在計算哈希函數時使用第一個單詞與第二個單詞各前四個字母時，全部化為小寫進行求解，利用平方取中法構造哈希函數，利用開放定址發解決沖突，其中需要調用詞組比較函數和詞組優先級比較函數；

1） 詞組比較函數

比較新詞組與哈希表中同一位置詞組是否為相同單詞；

2） 單詞優先比較函數

比較兩個相同詞組在字典輸出的情況下的先后次序；

6、 排序

?? 利用冒泡排序法對哈希結構體進行排序，將前十出現頻率的結構體返回主函數

7、文件輸出

利用ofstream函數進行reasult.txt文件的構造；

具體編碼：

1、 文件遍歷函數：

利用findfirst函數與findnext函數，不斷利用文件地址對文件進行遍歷，在遍歷的同時將地址字符串傳入到文件讀取子函數中；

2、 文件讀取函數：

在文件遍歷中調用此函數，利用傳入的地址和ifstream函數對文件進行打開操作，設置一個字符數組，再用getline函數將文件中的數據傳入數組中，由于getline是讀取文件的一行，此時便可以記錄行數的變化，當生成一個數組時便調用字符統計子函數并返回一個值代表字符數，調用單詞統計子函數并返回一個單詞數，調用詞組統計子函數不返回值。

3、 字符統計函數：

判斷從文件讀取子函數傳入的字符數組中的字符，并計數

4、 單詞統計函數：

從字符數組的首地址開始依次判斷，符合單詞的條件便調用單詞哈希構造子函數；

（1）單詞哈希構造函數：

利用單詞的前四位相同的條件，將其ASCLL碼值進行求和，再平方取模，得到的便是存入的地址，為了同時統計單詞的個數，構造了結構體數組，在結構體中存入單詞與頻率，在存入哈希表中時，如果地址處已存單詞，需要進行相同性的比較與優先級的比較，于是調用單詞比較子函數與單詞優先比較子函數；

（2）單詞比較函數：

比較傳入的兩個單詞，依次字符進行比較，遇見不同地方便進行判斷，如果相同字符數小于4個，則返回不同，如果大于4，則判斷之后是否全是數字；

（3）單詞優先比較函數：

此函數在單詞比較之后調用，此時傳入的兩個單詞均為相同，則先判斷相同字符的優先，如果相同則判斷不同的優先；

5、 詞組統計函數：

為了不與單詞發生交互，進行單獨構造，遇見單詞則判斷之后是否有單詞出現，如果沒有，從新的地址進行第一個單詞的判斷，如果有則調用詞組哈希構造，之后重復；

（1）????? 詞組哈希構造函數：

利用詞組的第一個單詞前4個字符與第二個單詞前4個字符的ASCLL值求和，平方取模，獲得地址，存入哈希表，構造一個結構體存儲詞組與頻率，在存儲的時候調用詞組比較與詞組優先比較函數，類似單詞哈希構造

（2）????? 詞組比較函數：

??? 先判斷第一個單詞是否相同，再判斷第二個，具體操作類似單詞比較；

（3）????? 詞組優先判斷函數：

??? 先判斷第一個單詞的優先，再判斷第二個，具體操作類似單詞優先比較；

6、 排序函數:

將單詞哈希表與詞組哈希表中的頻率進行排序，采取的是冒泡排序方法，為了同時輸出字符串和頻率，單獨構造了一個結構體存儲，此結構體存儲的是前十的字符串與頻率；

7、 文件輸出函數:

利用ofstream函數生成result.txt文件，并將答案寫入文件。

8、 main函數

主函數中調用了一次文件遍歷子函數，便是輸出的代碼。

?

測試結果：

自己構造的測試集：

文件小的時候只能輸出正確的行數、字符數與單詞數，文件一大程序就會崩潰；

助教給的測試集：

無法全部跑完；

崩潰原因分析：

1、 在讀取字符的時候使用的是getline，但之后的調試與編譯的時候，出現了數組溢出的事情，所以在get與getline的選擇上出現了錯誤，應該選擇更加安全的get，

2、 對于哈希表的構造不夠好，由于自己是用結構體數組，也會出現數據溢出的問題，還有關于哈希函數的構造也不夠好，容易發生沖突，導致的大量的計算與調用函數，使得程序運行很慢；

3、 在判斷單詞與詞組的時候，需要考慮的東西很多，很容易就會忽視一個，導致程序無法正常運行，由于多條條件的判斷導致自己很容易出錯；

4、 比較難以實現的是對哈希表的排序，最終確定了使用冒泡排序，這也導致了運行時間過長；

5、 各類細節問題，例如一開始使用的是int型數據，到最后才意識到了需要使用長整型，導致了代碼很多地方需要修改，以至于發生了一些不可描述的問題；

代碼優化：

1、 在一些循環語句中，例如for循環，一開始判定的條件是到達數組地址最大值的時候停止，經過考慮，于是使用了計算字符串長度的函數，將條件表達式的里的值改成了字符串真正懂得長度，但任然大量的調用了strlen函數，在代碼交上以后又想到了可以直接使用do……while循環，直接判斷數組為空，便可停止循環；

2、 盡量使用有符號長整型，但為了答案不會出錯，我選擇了無符號，這會大量浪費運行時間，應該將不需要無符號的數改為有符號；

3、 函數調用過于深，這次的程序發生了5層函數的調用，最好可以將其簡化；

4、 有一點沒用注意，便是沒用多使用const，因為如果一個const聲明的對象的地址不被獲取，允許編譯器不對它分配儲存空間。這樣可以使代碼更有效率，而且可以生成更好的代碼。

5、 熱行分析

?

由于采用了無比慢的排序方法導致的兩個sorting函數運行所占時間很多；

?

教訓與總結

首先從架構來說，自己在項目一開始的時候沒有確定一個特別明確的架構，導致在編碼的時候發現了思路不清楚的問題，之后才逐漸完善了架構，便浪費了不少時間，一個好的架構不僅在開發上有助于代碼的實現，還能解決程序耦合的問題；其次是沒有一個明確的設計方案，只是大致一想，就開始編碼，一邊編一邊想解決方案，導致了很深的函數調用，最終不易于調試與修改；再是自己在編碼的時候忘記了先編好輸出以便于一邊編一邊測試，導致了自己苦于編好了很多函數卻在測試時跳出了無數的bug，而且不易于修改，這個問題老師很早在課堂上提到過，要編幾行就進行測試，而自己卻沒有注意，運行的時候十分的后悔，過于復雜的程序導致了我不知如何去修改；最后就是書到用時方恨少，對于文件遍歷的問題自己將近花費了五分之一的時間，就是由于自己對于這個方面了解的太少，只能臨時抱佛腳，還有本來可以用C++的一些類就可以很容易解決的問題，只能自己利用C語言復雜的進行編寫，例如同學使用了一個C++中map的類就可以解決存儲的問題，自己感覺用的方法都很“蠢”，不夠靈活。

在這次個人作業中，我深深地感受到了自己在編碼方面的嚴重不足，不僅是對于各個語言的理解，還有是對于它們的靈活運用，由于自己知識儲備的嚴重不足，遇到問題都無法及時給出一個合適的解決方案，需要一個個去百度，甚至是去從頭去看書，在這個地方花費的時間將近有四分之一，導致了自己的思路不夠流暢，所以要加強自己對于編程書的閱讀，不能再拘泥于老師布置的任務，從現在開始要學習C++等更加便捷的語言，還有以后在編程之前要進行一次對于設計的思考，等到自己感覺設計已經明確并且可行時，再進行編碼，還有就是要注意好每一個細節，盡量在編碼的時候就最好注意到，最后也是我印象最深刻的就是隨時編碼隨時測試，多寫注釋，避免遺忘。綜上所述，簡言之就是“無他，唯手熟爾”，以后自己要多思考、多編程。

?

轉載于:https://www.cnblogs.com/Whydd/p/8678068.html

總結

以上是生活随笔為你收集整理的第一次工作报告的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。