Github地址c++
WordCountgit
PSP表格github
PSP2.1 | Personal Software Process Stages | 預估耗時(分鐘) | 實際耗時(分鐘) |
---|---|---|---|
Planning | 計劃 | ||
· Estimate | · 估計這個任務須要多少時間 | 5 | 5 |
Development | 開發 | ||
· Analysis | · 需求分析 (包括學習新技術) | 30 | 30 |
· Design Spec | · 生成設計文檔 | 30 | 0 |
· Design Review | · 設計複審 | 20 | 20 |
· Coding Standard | · 代碼規範 (爲目前的開發制定合適的規範) | 20 | 20 |
· Design | · 具體設計 | 30 | 30 |
· Coding | · 具體編碼 | 120 | 240 |
· Code Review | · 代碼複審 | 20 | 60 |
· Test | · 測試(自我測試,修改代碼,提交修改) | 60 | 120 |
Reporting | 報告 | ||
· Test Repor | · 測試報告 | 30 | 30 |
· Size Measurement | · 計算工做量 | 10 | 10 |
· Postmortem & Process Improvement Plan | · 過後總結, 並提出過程改進計劃 | 30 | 30 |
合計 | 345 | 595 |
代碼的實現算法
各函數的關係圖以下:數組
main()函數數據結構
主要負責文本文件的讀入,調用其餘函數及參數傳遞,並輸出函數返回的結果。函數
c_char()函數性能
接受main()函數傳入的文本字符串,統計文本中的有效字符數並返回。學習
c_line()函數測試
接受main()函數傳入的文件路徑,打開文件,以按行讀入的方式統計文本的行數並返回。
c_word()函數
本程序的最關鍵的部分,用了最直接的遍歷判斷法。
從首字符開始遍歷,利用char_judge()函數判斷當前字符是不是字母:
若不是字母,則判斷下一字符;
如果字母,則進入word_judge()函數判斷當前字母后的三位字符是不是字母:
若其後三位均是字母,則符合「單詞」條件,單詞數加1,進入單詞合成循環將其後的字符合併成一個單詞知道遇到非法字符爲止,並將單詞加入字符串數組word[i]存儲;
如有一位不是字母,則不符合「單詞」條件,返回檢測過的單詞數num,上層循環參數跳num位,再次執行循環。
遍歷結束後跳出循環,獲得合法單詞數並返回主函數,同時將合法單詞合成後存入字符串數組word[i],方便單詞頻率統計。
word_print()函數
利用word[i]數組中已存儲的單詞,遍歷後,去掉重複單詞,並統計出每一個單詞的頻率,以及單詞的acill碼值和,做爲排序條件;
用了最簡單但並不快捷的冒泡排序,以單詞頻率做爲首要排序條件,以單詞的acill碼值和做爲次要排序條件,對單詞進行排序;
排序後,輸出排名前10的單詞,以及其頻率;
代碼性能
一開始使用c++輸入輸出流函數來輸出,單次測試總執行時間達到了20s+;
因而,改用printf函數來輸出,單次測試結果以下:
單次執行後時間變成了12s+,有了很多的提高;
其他可改進的地方還有不少,好比:更好的數據結構、更好的排序算法等等,但由於時間緣由來不及改進,後面會繼續改進。
體會和感想
以前代碼被本身荒廢了好久,此次也算是經過此次做業撿起來一些,固然過程就顯得比較曲折。
在時間花費上,主要在編碼和Github的使用上花費了不少不少時間:
編碼問題是由於長期荒廢,遺忘和手生致使了編碼過程磕磕絆絆;
Github的使用出現了很多問題,到最後莫名出現了commit失敗沒法提交的問題,到如今也沒有解決,因此只能是提交第一版比較粗糙的代碼。
但整體來說,仍是有很大的收穫,撿起了荒廢了好久的代碼,讓我有一個新的開始;看過了別人的博客和代碼,讓我認識到本身的不足;一次次程序的debug、Github的崩潰、軟件功能的學習,讓我受益不淺;還有,就是如今最後時刻的博客編輯,鍛鍊了我良好的心態~