【正文】 后面。如果將函數(shù)聲明為：void StringCopy(char *strSource, char *strDestination)。別人在使用時(shí)可能會(huì)不假思索地寫成如下形式：char str[20]。StringCopy(str, “Hello World”)。 // 參數(shù)順序顛倒?? 【規(guī)則413】如果參數(shù)是指針，且僅作輸入用，則應(yīng)在類型前加const，以防止該指針在函數(shù)體內(nèi)被意外修改。例如void StringCopy(char *strDestination，const char *strSource)。?? 【規(guī)則414】如果輸入?yún)?shù)以值傳遞的方式傳遞對(duì)象，則宜改用“const amp。”方式來(lái)傳遞，這樣可以省去臨時(shí)對(duì)象的構(gòu)造和析構(gòu)過(guò)程，從而提高效率。?? 【建議415】避免函數(shù)有太多的參數(shù)，參數(shù)個(gè)數(shù)盡量控制在5 個(gè)以內(nèi)。如果參數(shù)太多，在使用時(shí)容易將參數(shù)類型或順序搞錯(cuò)。?? 【建議416】盡量不要使用類型和數(shù)目不確定的參數(shù)。C 標(biāo)準(zhǔn)庫(kù)函數(shù)printf 是采用不確定參數(shù)的典型代表，其原型為：int printf(const chat *format[, argument]?)。這種風(fēng)格的函數(shù)在編譯時(shí)喪失了嚴(yán)格的類型安全檢查。 返回值的規(guī)則?? 【規(guī)則421】不要省略返回值的類型。C 語(yǔ)言中，凡不加類型說(shuō)明的函數(shù)，一律自動(dòng)按整型處理。這樣做不會(huì)有什么好處，卻容易被誤解為void 類型。C++語(yǔ)言有很嚴(yán)格的類型安全檢查，不允許上述情況發(fā)生。由于C++程序可以調(diào)用C 函數(shù)，為了避免混亂，規(guī)定任何C++/ C 函數(shù)都必須有類型。如果函數(shù)沒(méi)有返回值，那么應(yīng)聲明為void 類型。?? 【規(guī)則422】函數(shù)名字與返回值類型在語(yǔ)義上不可沖突。違反這條規(guī)則的典型代表是C 標(biāo)準(zhǔn)庫(kù)函數(shù)getchar。例如：char c。c = getchar()。if (c == EOF)?按照 getchar 名字的意思，將變量c 聲明為char 類型是很自然的事情。但不幸的是getchar 的確不是char 類型，而是int 類型，其原型如下：int getchar(void)。由于c 是char 類型，取值范圍是[128，127]，如果宏EOF 的值在char 的取值范圍之外，那么if 語(yǔ)句將總是失敗，這種“危險(xiǎn)”人們一般哪里料得到！導(dǎo)致本例錯(cuò)誤的責(zé)任并不在用戶，是函數(shù)getchar 誤導(dǎo)了使用者。?? 【規(guī)則423】不要將正常值和錯(cuò)誤標(biāo)志混在一起返回。正常值用輸出參數(shù)獲得，而錯(cuò)誤標(biāo)志用return 語(yǔ)句返回?；仡櫳侠?，C 標(biāo)準(zhǔn)庫(kù)函數(shù)的設(shè)計(jì)者為什么要將getchar 聲明為令人迷糊的int 類型呢？他會(huì)那么傻嗎？在正常情況下，getchar 的確返回單個(gè)字符。但如果getchar 碰到文件結(jié)束標(biāo)志或發(fā)生讀錯(cuò)誤，它必須返回一個(gè)標(biāo)志EOF。為了區(qū)別于正常的字符，只好將EOF 定義為負(fù)數(shù)（通常為負(fù)1）。因此函數(shù)getchar 就成了int 類型。我們?cè)趯?shí)際工作中，經(jīng)常會(huì)碰到上述令人為難的問(wèn)題。為了避免出現(xiàn)誤解，我們應(yīng)該將正常值和錯(cuò)誤標(biāo)志分開(kāi)。即：正常值用輸出參數(shù)獲得，而錯(cuò)誤標(biāo)志用return 語(yǔ)句返回。函數(shù) getchar 可以改寫成BOOL GetChar(char *c)。雖然gechar 比GetChar 靈活，例如putchar(getchar())。 但是如果getchar 用錯(cuò)了，它的靈活性又有什么用呢？?? 【建議424】有時(shí)候函數(shù)原本不需要返回值，但為了增加靈活性如支持鏈?zhǔn)奖磉_(dá)，可以附加返回值。例如字符串拷貝函數(shù)strcpy 的原型：char *strcpy(char *strDest，const char *strSrc)。strcpy 函數(shù)將strSrc 拷貝至輸出參數(shù)strDest 中，同時(shí)函數(shù)的返回值又是strDest。這樣做并非多此一舉，可以獲得如下靈活性：char str[20]。int length = strlen( strcpy(str, “Hello World”) )。 函數(shù)內(nèi)部實(shí)現(xiàn)的規(guī)則不同功能的函數(shù)其內(nèi)部實(shí)現(xiàn)各不相同，看起來(lái)似乎無(wú)法就“內(nèi)部實(shí)現(xiàn)”達(dá)成一致的觀點(diǎn)。但根據(jù)經(jīng)驗(yàn)，我們可以在函數(shù)體的“入口處”和“出口處”從嚴(yán)把關(guān)，從而提高函數(shù)的質(zhì)量。?? 【規(guī)則431】在函數(shù)體的“入口處”，對(duì)參數(shù)的有效性進(jìn)行檢查。很多程序錯(cuò)誤是由非法參數(shù)引起的，我們應(yīng)該充分理解并正確使用“斷言”（assert）來(lái)防止此類錯(cuò)誤。?? 【規(guī)則432】在函數(shù)體的“出口處”，對(duì)return 語(yǔ)句的正確性和效率進(jìn)行檢查。如果函數(shù)有返回值，那么函數(shù)的“出口處”是return 語(yǔ)句。我們不要輕視r(shí)eturn語(yǔ)句。如果return 語(yǔ)句寫得不好，函數(shù)要么出錯(cuò)，要么效率低下。注意事項(xiàng)如下：（1）return 語(yǔ)句不可返回指向“棧內(nèi)存”的“指針”，因?yàn)樵搩?nèi)存在函數(shù)體結(jié)束時(shí)被自動(dòng)銷毀。例如char * Func(void){char str[] = “hello world”。 // str 的內(nèi)存位于棧上…return str。 // 將導(dǎo)致錯(cuò)誤}（2）要搞清楚返回的究竟是“值”、還是“指針”。 其它建議?? 【建議441】函數(shù)的功能要單一，不要設(shè)計(jì)多用途的函數(shù)。?? 【建議442】函數(shù)體的規(guī)模要小，盡量控制在50 行代碼之內(nèi)。?? 【建議443】盡量避免函數(shù)帶有“記憶”功能。相同的輸入應(yīng)當(dāng)產(chǎn)生相同的輸出。帶有“記憶”功能的函數(shù)，其行為可能是不可預(yù)測(cè)的，因?yàn)樗男袨榭赡苋Q于某種“記憶狀態(tài)”。這樣的函數(shù)既不易理解又不利于測(cè)試和維護(hù)。在C語(yǔ)言中，函數(shù)的static 局部變量是函數(shù)的“記憶”存儲(chǔ)器。建議盡量少用static 局部變量，除非必需。?? 【建議444】不僅要檢查輸入?yún)?shù)的有效性，還要檢查通過(guò)其它途徑進(jìn)入函數(shù)體內(nèi)的變量的有效性，例如全局變量、文件句柄等。?? 【建議445】用于出錯(cuò)處理的返回值一定要清楚，讓使用者不容易忽視或誤解錯(cuò)誤情況。 使用斷言程序一般分為Debug 版本和Release 版本，Debug 版本用于內(nèi)部調(diào)試，Release 版本發(fā)行給用戶使用。斷言 assert 是僅在Debug 版本起作用的宏，它用于檢查“不應(yīng)該”發(fā)生的情況。示例45 是一個(gè)內(nèi)存復(fù)制函數(shù)。在運(yùn)行過(guò)程中，如果assert 的參數(shù)為假，那么程序就會(huì)中止（一般地還會(huì)出現(xiàn)提示對(duì)話，說(shuō)明在什么地方引發(fā)了assert）。void *memcpy(void *pvTo, const void *pvFrom, size_t size){assert((pvTo != NULL) amp。amp。 (pvFrom != NULL))。 // 使用斷言byte *pbTo = (byte *) pvTo。 // 防止改變pvTo 的地址byte *pbFrom = (byte *) pvFrom。 // 防止改變pvFrom 的地址while(size 0 )*pbTo ++ = *pbFrom ++ 。return pvTo。}示例 45 復(fù)制不重疊的內(nèi)存塊assert 不是一個(gè)倉(cāng)促拼湊起來(lái)的宏。為了不在程序的Debug 版本和Release 版本引起差別，assert 不應(yīng)該產(chǎn)生任何副作用。所以assert 不是函數(shù)，而是宏。程序員可以把a(bǔ)ssert 看成一個(gè)在任何系統(tǒng)狀態(tài)下都可以安全使用的無(wú)害測(cè)試手段。如果程序在assert處終止了，并不是說(shuō)含有該assert 的函數(shù)有錯(cuò)誤，而是調(diào)用者出了差錯(cuò)，assert 可以幫助我們找到發(fā)生錯(cuò)誤的原因。很少有比跟蹤到程序的斷言，卻不知道該斷言的作用更讓人沮喪的事了。你化了很多時(shí)間，不是為了排除錯(cuò)誤，而只是為了弄清楚這個(gè)錯(cuò)誤到底是什么。有的時(shí)候，程序員偶爾還會(huì)設(shè)計(jì)出有錯(cuò)誤的斷言。所以如果搞不清楚斷言檢查的是什么，就很難判斷錯(cuò)誤是出現(xiàn)在程序中，還是出現(xiàn)在斷言中。幸運(yùn)的是這個(gè)問(wèn)題很好解決，只要加上清晰的注釋即可。這本是顯而易見(jiàn)的事情，可是很少有程序員這樣做。這好比一個(gè)人在森林里，看到樹(shù)上釘著一塊“危險(xiǎn)”的大牌子。但危險(xiǎn)到底是什么？樹(shù)要倒？有廢井？有野獸？除非告訴人們“危險(xiǎn)”是什么，否則這個(gè)警告牌難以起到積極有效的作用。難以理解的斷言常常被程序員忽略，甚至被刪除。?? 【規(guī)則451】使用斷言捕捉不應(yīng)該發(fā)生的非法情況。不要混淆非法情況與錯(cuò)誤情況之間的區(qū)別，后者是必然存在的并且是一定要作出處理的。?? 【規(guī)則452】在函數(shù)的入口處，使用斷言檢查參數(shù)的有效性（合法性）。?? 【建議453】在編寫函數(shù)時(shí)，要進(jìn)行反復(fù)的考查，并且自問(wèn)：“我打算做哪些假定？”一旦確定了的假定，就要使用斷言對(duì)假定進(jìn)行檢查。?? 【建議454】一般教科書都鼓勵(lì)程序員們進(jìn)行防錯(cuò)設(shè)計(jì)，但要記住這種編程風(fēng)格可能會(huì)隱瞞錯(cuò)誤。當(dāng)進(jìn)行防錯(cuò)設(shè)計(jì)時(shí)，如果“不可能發(fā)生”的事情的確發(fā)生了，則要使用斷言進(jìn)行報(bào)警。其它編程經(jīng)驗(yàn) 提高程序的效率程序的時(shí)間效率是指運(yùn)行速度，空間效率是指程序占用內(nèi)存或者外存的狀況。全局效率是指站在整個(gè)系統(tǒng)的角度上考慮的效率，局部效率是指站在模塊或函數(shù)角度上考慮的效率。?? 【規(guī)則511】不要一味地追求程序的效率，應(yīng)當(dāng)在滿足正確性、可靠性、健壯性、可讀性等質(zhì)量因素的前提下，設(shè)法提高程序的效率。?? 【規(guī)則512】以提高程序的全局效率為主，提高局部效率為輔。?? 【規(guī)則513】在優(yōu)化程序的效率時(shí)，應(yīng)當(dāng)先找出限制效率的“瓶頸”，不要在無(wú)關(guān)緊要之處優(yōu)化。?? 【規(guī)則514】先優(yōu)化數(shù)據(jù)結(jié)構(gòu)和算法，再優(yōu)化執(zhí)行代碼。?? 【規(guī)則515】有時(shí)候時(shí)間效率和空間效率可能對(duì)立，此時(shí)應(yīng)當(dāng)分析那個(gè)更重要，作出適當(dāng)?shù)恼壑?。例如多花費(fèi)一些內(nèi)存來(lái)提高性能。?? 【規(guī)則516】不要追求緊湊的代碼，因?yàn)榫o湊的代碼并不能產(chǎn)生高效的機(jī)器碼。 一些有益的建議?? 【建議521】當(dāng)心那些視覺(jué)上不易分辨的操作符發(fā)生書寫錯(cuò)誤。我們經(jīng)常會(huì)把“＝＝”誤寫成“＝”，象“||”、“amp。amp?！?、“=”、“=”這類符號(hào)也很容易發(fā)生“丟1”失誤。然而編譯器卻不一定能自動(dòng)指出這類錯(cuò)誤。?? 【建議522】變量（指針、數(shù)組）被創(chuàng)建之后應(yīng)當(dāng)及時(shí)把它們初始化，以防止把未被初始化的變量當(dāng)成右值使用。?? 【建議523】當(dāng)心變量的初值、缺省值錯(cuò)誤，或者精度不夠。?? 【建議524】當(dāng)心數(shù)據(jù)類型轉(zhuǎn)換發(fā)生錯(cuò)誤。盡量使用顯式的數(shù)據(jù)類型轉(zhuǎn)換（讓人們知道發(fā)生了什么事），避免讓編譯器輕悄悄地進(jìn)行隱式的數(shù)據(jù)類型轉(zhuǎn)換。?? 【建議525】當(dāng)心變量發(fā)生上溢或下溢，數(shù)組的下標(biāo)越界。?? 【建議526】當(dāng)心忘記編寫錯(cuò)誤處理程序，當(dāng)心錯(cuò)誤處理程序本身有誤。?? 【建議527】當(dāng)心文件I/O 有錯(cuò)誤。?? 【建議528】避免編寫技巧性很高代碼。?? 【建議529】不要設(shè)計(jì)面面俱到、非常靈活的數(shù)據(jù)結(jié)構(gòu)。?? 【建議5210】如果原有的代碼質(zhì)量比較好，盡量復(fù)用它。但是不要修補(bǔ)很差勁的代碼，應(yīng)當(dāng)重新編寫。?? 【建議5211】盡量使用標(biāo)準(zhǔn)庫(kù)函數(shù)，不要“發(fā)明”已經(jīng)存在的庫(kù)函數(shù)。?? 【建議5212】盡量不要使用與具體硬件或軟件環(huán)境關(guān)系密切的變量。?? 【建議5213】把編譯器的選擇項(xiàng)設(shè)置為最嚴(yán)格狀態(tài)。?? 【建議5214】如果可能的話，使用PCLint、LogiScope 等工具進(jìn)行代碼審查。“我應(yīng)該掌握什么程序設(shè)計(jì)語(yǔ)言更好？”你認(rèn)為該如何回答這個(gè)問(wèn)題？答：首先必須掌握C語(yǔ)言，面向?qū)ο蟮某绦蛟O(shè)計(jì)語(yǔ)言，各有各的優(yōu)勢(shì)，看你想往哪方面用了，如果是服務(wù)器端的應(yīng)用最好是java，跨平臺(tái)性好；如果是，一般的桌面應(yīng)用，C是較好的選擇；至于易上手程度，VB,Delphi等是上手比較快的；至于數(shù)據(jù)庫(kù)應(yīng)用本人認(rèn)為PB是最好的選擇，VB,Delphi也是比較好的選擇；當(dāng)特別強(qiáng)調(diào)效率的時(shí)候VC是不二的選擇，其中VC最為復(fù)雜，也最為靈活，“偷懶的程序員用VB，聰明的程序員用Delphi, 真正的程序員用VC”，如果想要設(shè)計(jì)一些系統(tǒng)級(jí)的核心程序，最好用VC，C語(yǔ)言也可，但是不如VC強(qiáng)大。無(wú)論什么語(yǔ)言，通一門即可，它們只是工具，設(shè)計(jì)模式和算法才是靈魂。，要求輸入一個(gè)學(xué)生的兩門課成績(jī)（百分制），計(jì)算該生的總分并要求輸出成績(jī)等級(jí)‘A’、‘B’、‘C’、‘D’、‘E’。總分在180分以上為‘A’，160~179分為‘B’，140~159分為‘C’，120~139分為‘D’，120分以下為‘E’。使用switch語(yǔ)句編寫，具體要求： ①成績(jī)通過(guò)鍵盤輸入，輸入之前要有提示信息。②若輸入的成績(jī)不是百分制成績(jī)，則給出錯(cuò)誤提示信息，并且不再進(jìn)行下面的等級(jí)評(píng)價(jià)；若輸入的成績(jī)是百分制成績(jī)，則計(jì)算總分，并根據(jù)要求評(píng)價(jià)等級(jí)。答：include include /*原型聲明*/ void input(int *,int*)。 int sum(int,int)。 void convert(int,char*)。 void degree(char,int)。void main(void){ /*定義變量*/ int nfst_course=1,nsec_course=1。 /*nfst_course第一門課成績(jī)，nsec_course第二門課成績(jī)*/ int *pfst=amp。nfst_course,*psec=amp。nsec_course。 char cdegree=39。\039。 /*成績(jī)等級(jí)*/ char *idegree=amp。cdegree。 int nsum。 clrscr()。/*清屏*/ do { input(pfst,psec)。