每到學(xué)期末總會有不少人捧著C課設(shè)題目來找我?guī)兔创a其中出現(xiàn)頻率最高的就是通訊錄管理系統(tǒng)。說實(shí)話這個(gè)題目被選中的概率極高因?yàn)槔蠋熛矚g它的完整性和可擴(kuò)展性學(xué)生覺得它看起來比圖書管理簡單一點(diǎn)。但實(shí)際上每次我打開這些代碼都能發(fā)現(xiàn)一大堆問題要么是純數(shù)組寫死容量要么是文件讀取各種亂碼要么是刪除聯(lián)系人后數(shù)據(jù)錯(cuò)亂。這篇文章我就結(jié)合自己做課設(shè)輔導(dǎo)時(shí)看到的真實(shí)情況把C通訊錄管理系統(tǒng)課程設(shè)計(jì)簡易版從題目拆解到代碼實(shí)現(xiàn)、再到答辯準(zhǔn)備一條龍講清楚。這個(gè)項(xiàng)目適合剛學(xué)完C基礎(chǔ)語法、打算用結(jié)構(gòu)體加文件流做第一個(gè)完整小系統(tǒng)的同學(xué)也適合那些想快速理解一個(gè)控制臺項(xiàng)目應(yīng)該如何組織代碼的人。我會盡量講清楚每一步為什么這么做因?yàn)槲乙娺^太多人跟著網(wǎng)上代碼抄一遍卻答不出任何設(shè)計(jì)理由最后在答辯時(shí)被問得啞口無言。1. 課程設(shè)計(jì)題目拆解一個(gè)簡單題目的隱藏難點(diǎn)1.1 題目的常規(guī)要求與評分點(diǎn)大部分學(xué)校給出的通訊錄管理系統(tǒng)要求都差不多我把它歸納成下面這幾條核心功能聯(lián)系人信息錄入姓名、電話號碼、QQ、郵箱、地址等顯示全部聯(lián)系人能夠把通訊錄里的記錄完整列出來按姓名查找聯(lián)系人輸入姓名后能定位到對應(yīng)記錄修改聯(lián)系人信息選中某條記錄并更新字段刪除聯(lián)系人按姓名刪除某個(gè)聯(lián)系人或清空全部文件保存與讀取程序退出后數(shù)據(jù)不丟失下次啟動能恢復(fù)如果只看這個(gè)列表好像每個(gè)功能都簡單但把它們組合在一起實(shí)現(xiàn)的時(shí)候真正的坑才會浮現(xiàn)出來。比如按姓名查找處理重名的問題刪除之后編號是否需要重新排列修改時(shí)直接覆蓋原文件還是先全部讀入內(nèi)存再整體寫回。這些細(xì)節(jié)才是評分拉開差距的地方。1.2 簡易版的正確理解功能少不等于代碼糙課程設(shè)計(jì)題目里寫了簡易版很多人就理解為功能能跑就行于是寫出一個(gè)只有main函數(shù)加幾百行if-else的代碼。這種態(tài)度在答辯時(shí)很容易翻車。我見過某位同學(xué)提交的代碼全程一個(gè)函數(shù)解決沒有結(jié)構(gòu)體用六個(gè)平行數(shù)組分別存姓名、電話、QQ刪除一條記錄就是要同步刪除六個(gè)數(shù)組的元素漏掉一個(gè)就導(dǎo)致數(shù)據(jù)錯(cuò)位。跑是跑得起來但老師隨便輸入一個(gè)不存在的姓名程序直接崩潰因?yàn)樵浇缭L問了。所以簡易版的準(zhǔn)確含義應(yīng)該是功能范圍不擴(kuò)展但代碼結(jié)構(gòu)、輸入處理、文件讀寫這些基本功必須扎實(shí)。用結(jié)構(gòu)體封裝數(shù)據(jù)、用函數(shù)拆分模塊、用vector管理動態(tài)數(shù)量這些不僅不會增加多少代碼量反而能省掉大量頭疼的bug。1.3 我建議的最小功能集結(jié)合大多數(shù)課程設(shè)計(jì)的要求我建議功能集保持下面這種粒度不多也不少功能模塊具體行為對應(yīng)核心知識點(diǎn)錄入依次輸入各項(xiàng)信息允許連續(xù)添加結(jié)構(gòu)體賦值、vector容器push_back顯示打印全部聯(lián)系人要求表格對齊循環(huán)遍歷、格式化輸出查找按姓名查找支持同名人全部列出string比較、遍歷匹配修改先查找后覆蓋字段引用傳遞、修改結(jié)構(gòu)體成員刪除按姓名刪除或提供清空選項(xiàng)vector迭代器erase操作排序按姓名字典序顯示sort函數(shù)或冒泡排序持久化啟動時(shí)從文件加載退出時(shí)保存ifstream/ofstream、分隔符解析這七個(gè)模塊基本覆蓋了課程設(shè)計(jì)的要求再多加功能比如分組、標(biāo)簽、生日提醒對簡易版來說屬于過度擴(kuò)展反而容易因?yàn)榇a不穩(wěn)定丟分。下面我按這個(gè)功能集展開講實(shí)現(xiàn)思路。2. 數(shù)據(jù)結(jié)構(gòu)選型為什么我勸你用vector而不是鏈表2.1 數(shù)組、鏈表和vector的三方對比很多初學(xué)者第一個(gè)想到的是結(jié)構(gòu)體數(shù)組因?yàn)樗钯N近課本。但數(shù)組最大的問題在于容量固定你聲明Contact contacts[100]如果某天錄入到第101個(gè)人程序要么報(bào)錯(cuò)要么默默丟失。有的同學(xué)會聲明contacts[1000]來規(guī)避但這本質(zhì)上是在賭數(shù)據(jù)量而且會造成內(nèi)存浪費(fèi)答辯時(shí)老師一句如果有一萬人呢就答不上來。鏈表單鏈表或雙向鏈表理論上很完美插入刪除都方便C語言課設(shè)里很常見。但問題是C課設(shè)階段很多同學(xué)的指針掌握并不牢固一個(gè)節(jié)點(diǎn)釋放錯(cuò)誤就會引發(fā)內(nèi)存泄漏或者野指針排查起來非常痛苦。而且鏈表不支持隨機(jī)訪問查找和排序都要多寫不少代碼。用std::vector是這三者里最適合課設(shè)的方案它不需要預(yù)知人數(shù)上限自動擴(kuò)容內(nèi)存連續(xù)分配訪問速度快支持隨機(jī)訪問和迭代器操作后面做查找、刪除、排序都有現(xiàn)成接口。它是數(shù)組的語法、動態(tài)的能力既不會讓代碼復(fù)雜化又能體現(xiàn)你掌握了STL容器的基礎(chǔ)使用。2.2 結(jié)構(gòu)體字段設(shè)計(jì)的幾個(gè)取舍聯(lián)系人信息字段不是越多越好也不是越少越好。我建議根據(jù)題目要求確定姓名和電話是必有的QQ、郵箱、地址這三個(gè)看題目是否要求。容易忽略的是備注字段比如大學(xué)同學(xué)、健身房教練這個(gè)字段在查找和展示時(shí)能體現(xiàn)項(xiàng)目的真實(shí)感。字段類型上電話建議用string而不是int。很多新手寫long long phone或者int phone這會導(dǎo)致兩個(gè)問題一是前面帶0的號碼如0136開頭會被當(dāng)成八進(jìn)制parse錯(cuò)誤或被截?cái)喽浅^int范圍的號碼直接溢出。用string存電話是最穩(wěn)妥的做法因?yàn)殡娫挷恍枰獏⑴c算術(shù)運(yùn)算只做存、取、比對而已。姓名用string也是同理中文姓名如果用char數(shù)組就得處理字符集對齊問題string則完全不用操心。整個(gè)結(jié)構(gòu)體定義大概是這樣的struct Contact { string name; // 姓名 string phone; // 電話號碼用string存避免前導(dǎo)0丟失 string qq; // QQ號同樣用string string email; // 郵箱 string address; // 地址 string remark; // 備注字段可選 };2.3 為什么聯(lián)系人編號是多余的有的同學(xué)會給每條記錄加上一個(gè)名為編號或id的int字段想著刪除時(shí)能精確定位。但實(shí)際使用中你會發(fā)現(xiàn)通訊錄應(yīng)用場景里用戶只記得姓名不會記得編號是多少號。如果加了編號刪除時(shí)要先顯示編號列表再讓用戶輸入編號那操作起來非常反直覺。更麻煩的是刪除中間某條記錄后后續(xù)記錄的編號要不要重新編排如果不重排就出現(xiàn)空洞如果重排就要修改所有后續(xù)記錄這又牽扯到引用和迭代器失效的坑。所以簡易版直接用姓名作為業(yè)務(wù)主鍵就夠了。遇到重名情況查找時(shí)輸出全部同名匹配項(xiàng)然后讓用戶根據(jù)電話區(qū)分哪一條是要修改或刪除的。這樣設(shè)計(jì)邏輯簡單符合真實(shí)使用習(xí)慣老師也無話可說。3. 功能模塊拆分從菜單循環(huán)到核心操作代碼3.1 菜單循環(huán)的順序與輸入緩沖區(qū)陷阱控制臺項(xiàng)目最常見的結(jié)構(gòu)就是do-while加switch菜單。菜單順序我建議按業(yè)務(wù)頻次排1顯示、2添加、3查找、4修改、5刪除、6排序、7保存并退出。退出時(shí)自動保存數(shù)據(jù)這樣用戶不會因?yàn)橥淈c(diǎn)保存而丟失錄入。菜單代碼很簡單但這里有一個(gè)十個(gè)人有九個(gè)人會踩的坑cin choice輸入數(shù)字后緩沖區(qū)里可能殘留一個(gè)換行符。如果接下來用cin.getline讀取姓名getline會立刻讀到那個(gè)殘留換行符返回一個(gè)空字符串看起來就像名字沒有輸入進(jìn)去。這個(gè)問題有三種常見解法每次輸入完菜單選項(xiàng)后調(diào)用cin.ignore()清除緩沖區(qū)殘留所有用戶輸入統(tǒng)一用getline讀取然后再把字符串轉(zhuǎn)成數(shù)字菜單選項(xiàng)用字符串讀取只判斷第一個(gè)字符我推薦第二種因?yàn)間etline處理姓名、地址這類含空格的文本時(shí)最穩(wěn)定而且和文件讀取用的方式一致代碼風(fēng)格統(tǒng)一。具體來說菜單讀取可以這樣做string input; getline(cin, input); int choice atoi(input.c_str());這樣即使用戶誤輸入abcatoi會返回0switch的default分支就能處理比cin choice直接類型崩潰安全得多。3.2 添加聯(lián)系人模塊與姓名查重添加模塊的邏輯不復(fù)雜定義一個(gè)Contact變量逐個(gè)getline讀取每個(gè)字段然后push_back進(jìn)vector。但這里值得多說一句查重。很多人的添加模塊不查重同一姓名可以存很多條后面的查找和刪除就分不清了。等到調(diào)試時(shí)自己都看暈了。我建議添加時(shí)遍歷一遍vector如果name相同就提示聯(lián)系人已存在不需要重復(fù)添加由用戶決定是否換成別的名字。這在代碼里只是幾行的開銷但對程序的健壯性提升很大。查重的實(shí)現(xiàn)是bool exists false; for (const auto c : contacts) { if (c.name newContact.name) { exists true; break; } }順帶一提添加成功后最好立刻輸出當(dāng)前聯(lián)系人總數(shù)讓用戶有反饋感這個(gè)細(xì)節(jié)在演示時(shí)很加分因?yàn)槔蠋熌苤庇^看到數(shù)據(jù)的變化。3.3 查找模塊精確匹配、模糊匹配和重名處理查找是通訊錄里最核心的交互。簡易版通常要求按姓名精確查找但如果你只做匹配用戶輸入張就什么都查不到體驗(yàn)相對生硬。我建議做一個(gè)前綴或包含匹配只要用戶輸入的關(guān)鍵字能作為姓名的子串就算命中。實(shí)現(xiàn)上就是把換成findvectorint matched; for (int i 0; i contacts.size(); i) { if (contacts[i].name.find(keyword) ! string::npos) { matched.push_back(i); } }用string::npos判斷是否找到子串這是C字符串處理的經(jīng)典操作。查找到結(jié)果后不要只返回一條而是把全部匹配項(xiàng)打印出來并附帶索引號讓用戶明確知道找到了誰。模糊匹配的額外好處是它在答辯時(shí)可以演示輸入一個(gè)偏旁也能查出來老師會認(rèn)為你具備工程思維而不是只會抄課本。同理修改和刪除模塊都是先查找、再操作的兩段式設(shè)計(jì)。修改模塊先查找到匹配項(xiàng)并打印出來讓用戶確認(rèn)要修改哪一條然后逐字段重新輸入覆蓋刪除模塊同理確認(rèn)后調(diào)用erase。之所以強(qiáng)調(diào)確認(rèn)環(huán)節(jié)是因?yàn)檎n設(shè)代碼沒有撤銷功能誤刪后數(shù)據(jù)就沒了二次確認(rèn)能防止演示時(shí)手滑。3.4 排序模塊字典序與排序穩(wěn)定性排序功能在很多課設(shè)要求里是加分項(xiàng)在簡易版里做到能按姓名升序顯示就夠了。C里最省事的方案是使用std::sort加上自定義比較函數(shù)#include algorithm bool compareByName(const Contact a, const Contact b) { return a.name b.name; } sort(contacts.begin(), contacts.end(), compareByName);這里直接比較string的運(yùn)算符它內(nèi)部就是按字典序比較的對英文姓名和拼音都有效。中文姓名在Windows控制臺下如果編碼一致比較的是編碼值但顯示效果通常符合預(yù)期不需要額外做漢字拼音轉(zhuǎn)換那是進(jìn)階版才需要的東西。4. 文件持久化格式設(shè)計(jì)比讀寫本身更重要4.1 兩種存儲方案的天壤之別簡易版通訊錄的文件存儲有兩種主流思路一是文本文件txt二是二進(jìn)制文件dat。文本文件的優(yōu)點(diǎn)是可以直接用記事本打開檢查數(shù)據(jù)方便調(diào)試和演示任何編輯器都能手動修改內(nèi)容。缺點(diǎn)是占空間略大解析時(shí)需要分割字符串。二進(jìn)制文件的優(yōu)點(diǎn)是存取速度快、不涉及分隔符轉(zhuǎn)義問題缺點(diǎn)是一旦字段結(jié)構(gòu)變化舊文件就完全沒法讀而且打開全是亂碼出了問題很難排查。課設(shè)幾乎沒有理由不選文本文件。老師檢查成績時(shí)很可能會直接打開你的數(shù)據(jù)文件看里面存得對不對如果是亂糟糟的二進(jìn)制文件第一印象就要扣分。所以我的結(jié)論很明確用txt文本文件每行一條聯(lián)系人記錄字段之間用豎線|分隔。4.2 分隔符選擇里的學(xué)問分隔符的選擇直接影響解析的難度。很多教程喜歡用逗號或空格但實(shí)際上地址字段里可能有逗號和空格會導(dǎo)致解析錯(cuò)位。豎線|、井號#這類符號在通訊錄的正常內(nèi)容里幾乎不會出現(xiàn)是更安全的分隔方案。存儲格式設(shè)計(jì)如下每行一條記錄張三|13800138000|123456|zhangsanexample.com|北京市海淀區(qū)|同事 李四|13900139000|654321|lisiexample.com|上海市浦東新區(qū)|同學(xué)對應(yīng)結(jié)構(gòu)體就是六個(gè)字段name表示姓名、phone表示電話、qq表示QQ號、email表示郵箱、address表示地址、remark表示備注。string本身沒有分隔符沖突問題整行用getline讀出再用stringstream和getline的第三個(gè)參數(shù)按分隔符拆分即可。讀取的核心代碼ifstream fin(contacts.txt); string line; while (getline(fin, line)) { stringstream ss(line); Contact c; getline(ss, c.name, |); getline(ss, c.phone, |); getline(ss, c.qq, |); getline(ss, c.email, |); getline(ss, c.address, |); getline(ss, c.remark, |); contacts.push_back(c); } fin.close();這里有個(gè)細(xì)節(jié)最后一個(gè)字段remark后面不能加|因?yàn)槲覀兠啃袛?shù)據(jù)只放五個(gè)分隔符。如果末尾多加一個(gè)豎線getline會多讀出一個(gè)空字符串。同理字段內(nèi)部不要包含換行否則會把一條記錄拆成兩行破壞整個(gè)文件的解析。4.3 保存時(shí)的整體寫回策略保存方式上新手最容易犯的錯(cuò)誤是只把新添加的聯(lián)系人追加到文件末尾。這樣做會帶來兩個(gè)問題一是如果修改或刪除了中間某條記錄舊的數(shù)據(jù)還在文件里下次啟動讀出來就重復(fù)了二是文件會越來越雜亂內(nèi)容順序和內(nèi)存順序不一致。正確做法是每次保存都把整個(gè)vector重新寫一遍文件。雖然效率上不如增量保存但通訊錄的數(shù)據(jù)量撐死幾百條寫入耗時(shí)可以忽略不計(jì)換來的是邏輯絕對正確ofstream fout(contacts.txt); for (const auto c : contacts) { fout c.name | c.phone | c.qq | c.email | c.address | c.remark \n; } fout.close();在程序啟動時(shí)打開文件加載到vector在退出前或每次操作后調(diào)用保存函數(shù)整個(gè)數(shù)據(jù)生命周期就完整了。要注意的是如果數(shù)據(jù)文件不存在ifstream打開會失敗這時(shí)應(yīng)該提示未找到數(shù)據(jù)文件將創(chuàng)建新通訊錄而不是讓程序崩潰。用if (fin.is_open())判斷一下空文件就跳過加載這種防御性寫法是答辯的加分項(xiàng)。5. 高頻報(bào)錯(cuò)的排查思路亂碼、閃退和數(shù)據(jù)錯(cuò)亂5.1 中文亂碼的根源與一套組合拳控制臺課程設(shè)計(jì)里中文亂碼幾乎是必踩的坑而且不同原因會呈現(xiàn)不同癥狀。最常見的一種是源代碼文件用UTF-8編碼保存而Windows控制臺默認(rèn)代碼頁是GBK即cp936中文字符在兩邊轉(zhuǎn)換時(shí)就顯示成一堆問號或韓文亂碼。這個(gè)問題有幾種解決思路。第一種是改控制臺代碼頁在程序入口調(diào)system(chcp 65001)把控制臺切成UTF-8模式但這種方式在部分Windows 10/11環(huán)境里字體渲染還是有問題而且程序會閃一下黑框。第二種是統(tǒng)一用GBK但現(xiàn)代編輯器默認(rèn)保存的是UTF-8每次都要手動改保存編碼比較麻煩。第三種是直接用setlocale(LC_ALL, chs)把C標(biāo)準(zhǔn)庫的本地化設(shè)置為簡體中文環(huán)境這在大多數(shù)MinGW和Visual Studio環(huán)境里都能解決讀寫中文的問題。就我的經(jīng)驗(yàn)最簡單省心的組合是編輯器里統(tǒng)一UTF-8編碼同時(shí)在main函數(shù)開頭加上setlocale(LC_ALL, chs);。這樣中文常量、中文輸入輸出、甚至中文文件內(nèi)容都能正常運(yùn)行基本不用再折騰。5.2 程序閃退與段錯(cuò)誤的幾類元兇閃退是課設(shè)調(diào)試階段的高頻事件只要用戶輸入一個(gè)非預(yù)期內(nèi)容就秒退。根據(jù)我的觀察90%的閃退都出自下面四類問題數(shù)組越界用固定數(shù)組時(shí)查找或刪除時(shí)索引超出聲明范圍。用vector且只通過迭代器和operator[]訪問且每次先檢查size基本可以避開?？誺ector上調(diào)用front或back通訊錄沒有任何數(shù)據(jù)時(shí)如果用戶先點(diǎn)修改或刪除代碼里如果有contacts.front()這樣的操作就會直接崩潰。正確做法是操作前先判斷contacts.empty()。解除引用野指針使用鏈表的代碼里常見的錯(cuò)誤這也是我勸你用vector的原因之一。vector的erase雖然會搬移元素但不會留下野指針訪問隱患。除零、整數(shù)溢出本項(xiàng)目的算術(shù)操作很少但如果你加了根據(jù)統(tǒng)計(jì)年齡平均之類的擴(kuò)展功能就要小心空數(shù)據(jù)集時(shí)除以0。5.3 修改和刪除后數(shù)據(jù)錯(cuò)亂數(shù)據(jù)錯(cuò)亂通常表現(xiàn)為修改A的姓名后B的電話也變成A的或者刪除第二條記錄后第三條和第四條的內(nèi)容重復(fù)。這背后的原因幾乎都是數(shù)據(jù)操作時(shí)沒有同步。如果你是六個(gè)平行數(shù)組方案改姓名時(shí)忘了同步修改電話數(shù)組這就是錯(cuò)亂的根源。用結(jié)構(gòu)體加vector的方案后改字段只涉及當(dāng)前一條結(jié)構(gòu)體成員的賦值刪除直接erase一個(gè)元素后面所有元素自動前移天然不會出現(xiàn)這種錯(cuò)亂。如果用了這種方案還出現(xiàn)錯(cuò)亂那大概率是文件保存和讀取的分隔符不一致——比如保存用|讀取卻按,拆分——導(dǎo)致字段整體錯(cuò)位。調(diào)試這種問題最好的辦法是直接用記事本打開生成的txt文件肉眼檢查每一行格式是否正確這比在程序里加日志快得多。6. 從簡易版到進(jìn)階版的演進(jìn)思路與答辯準(zhǔn)備6.1 進(jìn)階方向怎么選才能顯得有思考如果你的課程設(shè)計(jì)要求里已經(jīng)沒有簡易字樣或者你想在答辯時(shí)展示更多內(nèi)容有兩條比較推薦的擴(kuò)展路徑。第一條路是把存儲升級為數(shù)據(jù)庫文件。這里說的數(shù)據(jù)庫不一定是MySQL可以引入sqlite3這個(gè)輕量級庫把通訊錄數(shù)據(jù)入庫。這樣一來數(shù)據(jù)查詢、排序、去重都由SQL完成代碼量反而更少還能說明你具備數(shù)據(jù)庫意識。但前提是你的開發(fā)環(huán)境能順利集成sqlite很多學(xué)校的教室電腦沒有預(yù)裝庫演示前要自己驗(yàn)證過才行。第二條路是升級圖形界面。用Qt做一個(gè)簡單的窗口程序左側(cè)聯(lián)系人列表、右側(cè)信息編輯面板點(diǎn)擊列表項(xiàng)就能查看和修改信息。這個(gè)方向和純控制臺項(xiàng)目完全是兩種體驗(yàn)老師看到圖形界面的時(shí)候通常都會眼前一亮。代價(jià)是項(xiàng)目復(fù)雜度成倍上升代碼從幾百行變成幾千行而且Qt環(huán)境的安裝配置也可能花掉一個(gè)下午。我的建議是如果平時(shí)C成績一般優(yōu)先把控制臺版本做扎實(shí)不要盲目上圖形界面如果基礎(chǔ)較好且時(shí)間充裕Qt版會帶來更好的評分回報(bào)。6.2 答辯時(shí)最容易被追問的幾個(gè)問題答辯本質(zhì)上就是看你能不能解釋自己做的東西。根據(jù)我當(dāng)助手時(shí)旁聽的經(jīng)驗(yàn)老師最喜歡問這幾個(gè)問題提前想好答案為什么用vector不用數(shù)組答數(shù)組容量固定無法應(yīng)對未知數(shù)據(jù)量vector自動擴(kuò)容且支持隨機(jī)訪問查找效率高代碼也更簡潔。文件打開失敗怎么辦答程序啟動時(shí)通過is_open()檢查文件是否存在不存在則創(chuàng)建空通訊錄等待用戶錄入保存時(shí)確保目錄可寫。這個(gè)回答一定要有具體代碼支撐不能只是口頭上說我做了容錯(cuò)。刪除中間元素后vector的內(nèi)存發(fā)生了什么答erase之后被刪除元素之后的所有元素會前移size減小但capacity不一定變化。如果答不出capacity和size的區(qū)別老師基本一眼就看穿你的STL是臨時(shí)背的。多個(gè)人重名你的程序怎么區(qū)分答查找時(shí)輸出所有匹配項(xiàng)和完整信息由用戶確認(rèn)到底選擇哪一條。這個(gè)邏輯也體現(xiàn)在我的修改和刪除模塊里。6.3 展示小技巧多少條數(shù)據(jù)演示效果最好最后分享一個(gè)答辯演示和數(shù)據(jù)準(zhǔn)備的技巧。通訊錄里不要只放兩三條數(shù)據(jù)那樣看起來太寒酸也體現(xiàn)不出遍歷和排序的效果但也不要放幾百條翻頁翻得人眼花。我建議放十五到二十條數(shù)據(jù)盡量讓姓名分布有明顯差異比如既有張偉王芳這種高頻重名也有歐陽娜娜上官婉兒這類復(fù)姓這樣你演示重名查重、模糊匹配和字典序排序時(shí)都有合適的素材。數(shù)據(jù)里的電話和QQ號盡量用不同號段的方便別人認(rèn)出這就是那條記錄。地址可以分布在幾個(gè)城市備注填上同學(xué)家人同事等不同類別。這些數(shù)據(jù)本身不用花多少時(shí)間準(zhǔn)備但在答辯現(xiàn)場能極大提升演示的流暢程度因?yàn)槊總€(gè)功能你都可以挑一條合適的數(shù)據(jù)來操作講起來比臨時(shí)亂輸入一通要從容得多。我自己在實(shí)際幫人調(diào)試這類項(xiàng)目時(shí)體會最深的一點(diǎn)是通訊錄管理系統(tǒng)雖然簡單但它把結(jié)構(gòu)體、容器、字符串處理、文件流和模塊化設(shè)計(jì)這五個(gè)C核心知識點(diǎn)全部串起來了。把這樣一個(gè)項(xiàng)目從零寫一遍、調(diào)通、再在答辯時(shí)講明白你對C的實(shí)際掌握程度會比背十遍語法書都扎實(shí)。如果你正好在做這個(gè)課設(shè)按著我上面講的思路一步步實(shí)現(xiàn)遇到問題多想想為什么最后交上來的代碼一定會比大多數(shù)同學(xué)高出幾個(gè)檔次。