標(biāo)題?? 防御性編碼和單元測(cè)試規(guī)則(一)??????chensheng913 [原作]??
關(guān)鍵字?? 防御性編碼和單元測(cè)試規(guī)則(一)??
出處????
開(kāi)發(fā)人員編寫(xiě)代碼。不幸的是，開(kāi)發(fā)人員也編寫(xiě)缺陷，其中大多數(shù)缺陷是在最初的編碼階段加入的。修復(fù)這些缺陷成本最低的地方同樣也是在開(kāi)發(fā)的初始階段。如果等到功能測(cè)試或者系統(tǒng)測(cè)試來(lái)捕獲并修復(fù)缺陷，那么您的軟件開(kāi)發(fā)成本就會(huì)高得多。在本文中，作者 Scott Will、Ted Rivera 和 Adam Tate 討論了一些基本的“防御性”編碼和單元測(cè)試實(shí)踐，讓開(kāi)發(fā)人員更容易找到缺陷 —— 更重要的是，從一開(kāi)始預(yù)防缺陷產(chǎn)生。
防御性駕駛和防御性開(kāi)發(fā)
大多數(shù)司機(jī)接受過(guò)防御性駕駛技術(shù)的教育 —— 這有很好的理由 —— 但是并不是所有開(kāi)發(fā)人員都接受過(guò)防御性開(kāi)發(fā)的教育，特別是那些沒(méi)有用匯編語(yǔ)言進(jìn)行過(guò)多少開(kāi)發(fā)（如果不是完全沒(méi)用過(guò)的話）、也沒(méi)有因內(nèi)存約束和處理器限制而關(guān)心過(guò)編寫(xiě)極其緊湊的代碼的年輕開(kāi)發(fā)人員。本文討論防御性編碼和單元測(cè)試概念，它們可以幫助開(kāi)發(fā)人員更快生成更好的代碼并且缺陷更少。
為什么防御性開(kāi)發(fā)是重要的？
捕捉錯(cuò)誤、問(wèn)題和缺陷的最佳位置是在開(kāi)發(fā)周期的早期。圖 1 展示了最容易出現(xiàn)缺陷的地方，以及最容易發(fā)現(xiàn)它們的地方，并包括了修復(fù)這些缺陷的成本（這些成本是針對(duì) 1996 年的 —— 今天的成本顯然更高）。
圖 1. 缺陷：引入階段及發(fā)現(xiàn)階段（包括成本）
當(dāng)然，比在編碼階段找到缺陷更好的是在一開(kāi)始就防止它們。防止缺陷應(yīng)該是開(kāi)發(fā)人員最優(yōu)先考慮的。我們將分析幾個(gè)讓開(kāi)發(fā)人員可以在編碼和單元測(cè)試時(shí)防止并檢測(cè)缺陷的簡(jiǎn)單的、經(jīng)過(guò)證明的方法。
在編譯前（防御性設(shè)計(jì)考慮）
防止缺陷（特別是系統(tǒng)性缺陷）的最有效方式是仔細(xì)檢查編碼所依據(jù)的設(shè)計(jì)。由設(shè)計(jì)缺陷導(dǎo)致的缺陷 —— 雖然一般不是很多 —— 通常修補(bǔ)成本是最高的。事前花很少的時(shí)間針對(duì)以下幾點(diǎn)對(duì)設(shè)計(jì)進(jìn)行檢查可以得到顯著的長(zhǎng)期回報(bào)。
設(shè)計(jì)考慮
設(shè)計(jì)是否有任何不清楚或者混亂的部分？如果是的話，在編寫(xiě)任何代碼 之前 澄清這些問(wèn)題。否則，您可能以一種方式解釋一個(gè)設(shè)計(jì)需求，而同事則以另一種方式解釋它，從而得到不兼容的實(shí)現(xiàn)。
如果您的代碼要訪問(wèn)同時(shí)被其他組件訪問(wèn)的數(shù)據(jù)，那么保證您的設(shè)計(jì)可以處理這種情況。同時(shí)，檢查設(shè)計(jì)的安全問(wèn)題。
如果您的代碼嚴(yán)重依賴于其他應(yīng)用程序的代碼，那么您對(duì)那個(gè)應(yīng)用程序是否熟悉到可以對(duì)設(shè)計(jì)進(jìn)行檢查？考慮在您的設(shè)計(jì)檢查小組中加入熟悉該產(chǎn)品的一個(gè)開(kāi)發(fā)人員。在 設(shè)計(jì)階段 發(fā)現(xiàn)的集成問(wèn)題可以得到最有效的處理。
安裝和使用考慮
如果您的代碼是以前版本的一個(gè)升級(jí)，那么是否有會(huì)使升級(jí)失敗的參數(shù)或者其他選項(xiàng)改變？有哪些其他產(chǎn)品與新代碼交互或者集成 —— 如果這些產(chǎn)品本身也改變了呢？還有，您的代碼是否容易安裝？
操作系統(tǒng)和數(shù)據(jù)庫(kù)考慮
您的代碼是否會(huì)在新版本的操作系統(tǒng)或者數(shù)據(jù)庫(kù)上運(yùn)行？您是否知道這些新版本中加入了哪些改變以及它們是否（及如何）影響您的代碼？
這只是測(cè)試
設(shè)計(jì)是否結(jié)合了可測(cè)試性？雖然您可能認(rèn)為可測(cè)試性問(wèn)題不是您需要關(guān)心的，但是事實(shí)上單元測(cè)試 是 開(kāi)發(fā)人員的責(zé)任之一 —— 幾乎所有使執(zhí)行功能測(cè)試和/或系統(tǒng)測(cè)試更容易的任何事情也會(huì)使單元測(cè)試更容易執(zhí)行。
下面是 可測(cè)試性 領(lǐng)域內(nèi)容的幾個(gè)例子。
設(shè)計(jì)是否允許運(yùn)行時(shí)外部工具訪問(wèn)“狀態(tài)”變量（例如，當(dāng)前狀態(tài)），特別是那些測(cè)試程序需要用來(lái)驗(yàn)證代碼是否正確工作以幫助確定問(wèn)題的變量？
是否對(duì)跟蹤和日志給予了足夠的重視？您讓其他人分析缺陷越容易，您在發(fā)現(xiàn)缺陷后修正它們就越容易（而且在單元測(cè)試中發(fā)現(xiàn)自己的問(wèn)題也會(huì)更容易）。
您是否考慮了所有可能調(diào)用您的代碼的上下文？如果您可以將錯(cuò)誤消息與調(diào)用它的用戶函數(shù)上下文相關(guān)聯(lián)，那么用戶就更有可能理解這個(gè)錯(cuò)誤。
設(shè)計(jì)是否結(jié)合了您的測(cè)試自動(dòng)化工具所需要的特定的“鉤子（hook）”？
再多想一想您肯定可以在這個(gè)清單中加入更多的內(nèi)容，特別是那些對(duì)您的產(chǎn)品或者組織特定的內(nèi)容。
防御性編碼技術(shù)：編譯器是您的朋友
當(dāng)您完成對(duì)設(shè)計(jì)的檢查后，就輪到編碼了。就讓我們面對(duì)它，除了設(shè)計(jì)錯(cuò)誤外，編碼是惟一引入缺陷的地方。無(wú)論如何，您的測(cè)試程序和客戶是不會(huì)加入缺陷的 —— 只有 您 會(huì)。我們都知道時(shí)間很緊張，但是如果您沒(méi)有時(shí)間在第一次就把它編寫(xiě)正確，那么您怎么能找到時(shí)間去修正它呢？花上一些時(shí)間，這會(huì)使您在以后的編碼工作中更輕松。
防止缺陷的最好方法之一是使用編譯器。令人恐懼的是，開(kāi)發(fā)人員在編譯時(shí)通常選擇使用最低程度的警告輸出，所以請(qǐng)啟用編譯的全部警告 —— 把即使將編譯器配置為檢查 所有方面 編譯時(shí)也不產(chǎn)生一個(gè)警告當(dāng)成編寫(xiě)代碼的一個(gè)挑戰(zhàn)。此外，對(duì)代碼使用多種編譯器使很多程序員獲益 —— 這種方法有時(shí)會(huì)捕獲不同的語(yǔ)法錯(cuò)誤。
編碼習(xí)慣
下面我們將拋磚引玉介紹幾個(gè)好的編碼習(xí)慣。我們不是要為您定義“最佳編碼習(xí)慣” —— 我們只是要您形成自己遵守的代碼編寫(xiě)習(xí)慣。下面是幾個(gè)供參考的最佳習(xí)慣的例子。
在使用前初始化所有變量
您是否有一組可接受的默認(rèn)值，特別是對(duì)于可能被用戶、其他組件或者其他程序有選擇地修改的數(shù)據(jù)？同時(shí)，我們強(qiáng)烈要求您列出在最外圍例程中要使用的所有本地變量，然后再專門(mén)初始化它們。這樣不會(huì)對(duì)您編寫(xiě)代碼時(shí)的想法留下任何疑問(wèn)。雖然這可能要多花一些時(shí)間并且像是沒(méi)有理由地增加了幾行代碼，但是與只是在“運(yùn)行中（on the fly）”聲明本地變量相比，大多數(shù)優(yōu)化編譯器不會(huì)對(duì)此生成任何額外的運(yùn)行時(shí)代碼。清單 1 顯示了在一個(gè)例程中最初幾行代碼的一個(gè)例子：
清單 1. 初始化本地變量
public unsigned short TransMogrify( UFEventLink IncomingLink )
??{
????//
????// local variables
????//
????unsigned short usRc;
????String sOurEventType;
????String sTheirEventType;
????//
????// beginning of code
????//
????usRc = 0;
????sOurEventType = null;
????sTheirEventType = null;
????//
????// a miracle occurs...
????//
????return( usRc );
??} // end "TransMogrify"
使用一個(gè)“編碼標(biāo)準(zhǔn)”文檔
如果您有一個(gè)編碼標(biāo)準(zhǔn)文檔，就使用它。您可以在 Internet 上找到許多種編碼標(biāo)準(zhǔn)。找到一種簡(jiǎn)單的、切中要害、并為您留下一定的活動(dòng)空間的標(biāo)準(zhǔn)。Sun 的網(wǎng)站有一個(gè)關(guān)于 Java 編程的編碼規(guī)范的文章（請(qǐng)參閱 參考資料），它給出了擁有標(biāo)準(zhǔn)的下列幾點(diǎn)理由：
一個(gè)軟件生存期百分之八十的成本都用在維護(hù)上。
幾乎沒(méi)有軟件在整個(gè)使用期間都是由原作者維護(hù)的。
編碼規(guī)范改進(jìn)了軟件的可讀性，使工程師可以更快和更充分地理解新代碼。
如果您將源代碼作為產(chǎn)品交付，那么需要保證它有像您創(chuàng)建的所有其他產(chǎn)品一樣的包裝和整潔性。
即使不贊成“標(biāo)準(zhǔn)”的想法，至少采用這個(gè)簡(jiǎn)單的建議：對(duì)變量名使用“匈牙利命名法”，這會(huì)使您的代碼更容易閱讀和維護(hù)（。
保證返回代碼的一致性
在調(diào)試時(shí)有一種會(huì)制造麻煩的情況是：調(diào)用程序屏蔽（或者覆蓋）一個(gè)表示錯(cuò)誤的返回代碼。一定要想好您要向調(diào)用您的代碼的例程返回什么值，并保證從您所調(diào)用的例程返回的所有錯(cuò)誤代碼都得到恰當(dāng)處理。如果返回代碼 n 在一個(gè)地方意味著一件事，就不要在其他的地方用返回代碼 n 表示另一件事。
對(duì)每個(gè)例程使用“單點(diǎn)退出”
這一點(diǎn)怎么強(qiáng)調(diào)也不過(guò)分：對(duì)每個(gè)例程使用單點(diǎn)退出 —— 就是說(shuō)，沒(méi)有多重返回！這是最容易忽視的、也是您可以采用的最好的習(xí)慣。如果例程只從一個(gè)地方返回，那么就可以用一種非常容易的方法保證在返回前完成所有必要的清理工作，這也使調(diào)試更容易。清單 2 顯示了一個(gè)包含多重返回的代碼示例。注意重復(fù)代碼、甚至忘記“清理”項(xiàng)目是多么容易。
清單 2. 單點(diǎn)退出示例
1?? public String getName( )
2???? {
3?????? //
4?????? // local variables
5?????? //
6?????? String returnString;
7
8
9?????? //
10??????// beginning of code
11??????//
12??????returnString = textField.getText( );
13??????if ( null == returnstring )
14????????{
15??????????badCount++;
16??????????totalCount++;
17??????????return( null )
18????????}
19
20??????returnString = returnString.trim( );
21??????if ( returnString.equals( "" ) )
22????????{
23??????????badCount++;
24??????????totalCount++;
25??????????return( null );
26????????}
27
28??????totalCount++;
29??????return( returnString );
30
31????} // end getName
在第 15 行，badCount 增加了，因?yàn)?getText( ) 返回 null。在第 23 行，badCount 代碼又重復(fù)了。現(xiàn)在想像一下如果這個(gè)例子需要完成更復(fù)雜的“清理”時(shí)會(huì)有多混亂。
清單 3 顯示了一種更好的方法：
清單 3. 單點(diǎn)退出示例 —— 修正后
1?? public String getName( )
2???? {
3?????? //
4?????? // local variables
5?????? //
6?????? String returnString;
7
8
9?????? //
10??????// beginning of code
11??????//
12??????returnString = textField.getText( );
13??????if ( null != returnstring )
14????????{
15??????????returnString = returnString.trim( );
16??????????if ( returnString.equals( "" ) )
17????????????returnString = null;
18????????}
19
20??????//
21??????// "cleanup"
22??????//
23??????if ( null == returnString )
24????????badCount++;
25??????totalCount++;
26
27??????return( returnString );
28
29????} // end getName
標(biāo)題?? 防御性編碼和單元測(cè)試規(guī)則(二)??????chensheng913 [原作]??
關(guān)鍵字?? 防御性編碼和單元測(cè)試規(guī)則(二)?? 出處???? 加強(qiáng)警戒（En garde）! 要記住，您的客戶對(duì)您的產(chǎn)品有與您不一樣的想法。他們會(huì)在一個(gè)您的小組很可能從來(lái)也沒(méi)想到的 —— 或者至少是沒(méi)有可能測(cè)試的 —— 環(huán)境中安裝它。他們會(huì)以您從來(lái)沒(méi)有想到過(guò)的方法使用它，并以您意想不到的方法配置它。下面的列表有助于幫助您保證他們不會(huì)發(fā)怒： 驗(yàn)證所有收到的參數(shù)的完整性（考慮如果您期待一個(gè)數(shù)組而傳遞來(lái)的是一個(gè) null，但是您在索引數(shù)組之前沒(méi)有檢查這種可能性時(shí)會(huì)發(fā)生什么情況）。 考慮所有可能的錯(cuò)誤情況并增加處理每種情況的代碼（您希望代碼得體地處理錯(cuò)誤條件而不是堵塞它）。 對(duì)于那些未預(yù)料到的錯(cuò)誤條件，加入一個(gè)一般性的“捕獲所有”錯(cuò)誤處理程序。 在適當(dāng)?shù)臅r(shí)候和地點(diǎn)使用常量。 在代碼各處加入跟蹤和日志。 如果您的產(chǎn)品將翻譯為另一種語(yǔ)言，那么保證您的代碼可以“支持”它。即使出現(xiàn)這種情況的機(jī)會(huì)很小，但是提前計(jì)劃總是好一些。修改代碼以使它提供支持是最容易產(chǎn)生缺陷的。下面是幾個(gè)您要考慮的與支持相關(guān)的問(wèn)題： 您是否有任何硬編碼的字符串？ 您是否正確地處理不同的日期/時(shí)間？ 不同的貨幣表示呢？ 還有，在代碼中使用大量斷言。 給您的代碼加上充分的 注釋。總之，您還記得在六個(gè)月前編寫(xiě)那個(gè)方法時(shí)的想法嗎？一年后要修改您的代碼的某個(gè)人又會(huì)怎么想呢？在我們提出的所有建議中，這一條可能是最重要的。 單元測(cè)試（防御性測(cè)試技術(shù)） 在本文中，我們所說(shuō)的 單元測(cè)試 是開(kāi)發(fā)人員在自己的代碼正確編譯后、在交給功能測(cè)試小組之前進(jìn)行的所有測(cè)試和分析。正如我們?cè)?這只是一個(gè)測(cè)試 中提到的，主動(dòng)進(jìn)行單元測(cè)試并 在測(cè)試時(shí)像一位測(cè)試者那樣思考（即，必須往壞處想、熱衷于破壞并喜歡惡作劇）是很重要的。下面是在單元測(cè)試時(shí)要記住的幾件事。 靜態(tài)代碼分析工具 第一種，也是最容易的分析代碼的方法是讓別人替您做 —— 或者像在這里一樣，讓其他 工具 替您做。有一些不同的靜態(tài)代碼分析工具可用，從綜合性的工具 —— 一些開(kāi)發(fā)機(jī)構(gòu)實(shí)際上在他們的“編譯”環(huán)境（這可是需要購(gòu)買(mǎi)的）中加入了這樣的工具 —— 到其他可以免費(fèi)從 Internet 上下載的工具。 發(fā)現(xiàn)缺陷 當(dāng)您準(zhǔn)備運(yùn)行代碼并檢查缺陷時(shí)，要記住往壞處想。這些缺陷是您所創(chuàng)建的或者由您忽略的代碼產(chǎn)生。下面是一些幫助您找到代碼中缺陷的提示： 試著強(qiáng)行制造您所想到的所有錯(cuò)誤條件并檢查可以出現(xiàn)的所有錯(cuò)誤消息。 試著使用與其他組件或者程序交互的代碼路徑。如果其他程序或者組件還不存在，那么就自己編寫(xiě)一些腳手架代碼以使您可以試用 API 或者填充共享內(nèi)存、共享隊(duì)列，等等。并讓您的功能測(cè)試小組可以使用這個(gè)腳手架代碼，這樣他們就可以把它加入到他們的武器庫(kù)中。 對(duì)于 GUI 中的每一個(gè)輸入字段，試驗(yàn)下面多種不同的組合（考慮 自動(dòng)化）： 不可接受的字符（控制字符、非打印字符等）。 過(guò)多的字符。 過(guò)少的字符。 負(fù)數(shù)（特別是當(dāng)您只期待正數(shù)時(shí)）。 過(guò)大和/或者過(guò)小的數(shù)。 剪切和粘貼數(shù)據(jù)和文本到輸入字段，特別是當(dāng)您編寫(xiě)的代碼限制用戶可以鍵入該字段的內(nèi)容時(shí)。 文本和數(shù)字的組合。 全大寫(xiě)字母和全小寫(xiě)字母。 為代碼創(chuàng)建“壓力條件”，如大量活動(dòng)、慢連接的網(wǎng)絡(luò)和所有您想到的可以將代碼推到極限條件的東西。 反復(fù)進(jìn)行同樣的步驟，然后： 檢查未預(yù)計(jì)到的內(nèi)存損失條件。 檢查當(dāng)內(nèi)存用光時(shí)發(fā)生什么。 試圖創(chuàng)建緩存溢出、滿隊(duì)列、不可用的緩存以及其他“不能正確工作”的情況。 對(duì)于數(shù)組和緩存，試著向數(shù)組（或者緩存）增加 n 個(gè)數(shù)據(jù)項(xiàng)，然后試圖刪除 n+1 個(gè)項(xiàng)。 關(guān)于時(shí)間的考慮？ 如果操作“b”在操作“a”之前發(fā)生會(huì)怎么樣？就算您 認(rèn)為 它不會(huì)發(fā)生 —— 您能 使 它發(fā)生嗎？如果是的話，可以打賭您的客戶會(huì)使它發(fā)生的。最好現(xiàn)在找出來(lái)，而不是在修復(fù)成本更高、并聽(tīng)到客戶報(bào)怨您的軟件質(zhì)量糟糕之后再去做。 腳手架代碼 我們?cè)谇懊?發(fā)現(xiàn)缺陷 中討論了腳手架代碼。如果是為自己的使用需要而創(chuàng)建的，一定要將它交給驗(yàn)證工程師。可能您提供的腳手架代碼使他們可以很快地開(kāi)始測(cè)試您的代碼，或者至少使他們更好地理解當(dāng)其他組件存在時(shí)可以預(yù)期什么。 如果您的產(chǎn)品有保護(hù)性的安全功能，那么您必須測(cè)試它們。提供可以創(chuàng)建您想要防止的情況的腳手架代碼是很重要的：您必須能夠創(chuàng)建系統(tǒng)試圖防止的那種情況。 腳手架代碼的另一個(gè)簡(jiǎn)單例子是提供操縱隊(duì)列的代碼。如果您的產(chǎn)品使用隊(duì)列，那么想像如果有一個(gè)可以在運(yùn)行時(shí)從隊(duì)列中增加或者刪除項(xiàng)、破壞隊(duì)列中的數(shù)據(jù)（以保證適當(dāng)?shù)腻e(cuò)誤處理）等等的工具會(huì)有多方便。 源代碼級(jí)調(diào)試程序 使用源代碼級(jí)的調(diào)試程序是進(jìn)行徹底和成功的單元測(cè)試的關(guān)鍵方法。開(kāi)發(fā)人員應(yīng)該與他們的調(diào)試程序共生死。不幸的是，對(duì)源代碼級(jí)的調(diào)試程序的充分了解和使用是一種正在消亡的做法，盡管這些調(diào)試程序的好處遠(yuǎn)遠(yuǎn)超過(guò)任何學(xué)習(xí)曲線。簡(jiǎn)而言之，我們強(qiáng)烈鼓勵(lì)您全面學(xué)習(xí)一種調(diào)試程序。下面是用源代碼級(jí)調(diào)試程序?qū)Υa進(jìn)行單元測(cè)試的幾種方法。您可以： 在運(yùn)行中操縱數(shù)據(jù) —— 例如，在輸入代碼時(shí)設(shè)置中斷點(diǎn)，然后重新設(shè)置傳遞的參數(shù)值以檢查代碼是否能正確處理（現(xiàn)在為）無(wú)效的參數(shù)。以這種方式使用調(diào)試程序就不需要讓錯(cuò)誤條件真正發(fā)生。 設(shè)置斷點(diǎn)，然后“單步”通過(guò)代碼，這樣您就可以看到每一行代碼所做的事情。 設(shè)置對(duì)變量的“監(jiān)視（watch）”。 強(qiáng)制使用錯(cuò)誤代碼路徑。 觀察調(diào)用堆棧以檢查哪一個(gè)例程調(diào)用了您的代碼。 在錯(cuò)誤發(fā)生時(shí)“捕獲”它們。 執(zhí)行邊界檢查。 認(rèn)識(shí)您的驗(yàn)證工程師 驗(yàn)證工程師是測(cè)試知識(shí)的很好來(lái)源。他們可以給您指出要測(cè)試什么并幫助您了解可以在代碼中加入什么以幫助他們測(cè)試（如代碼鉤子）。此外，您可以向他們展示如何使用您的腳手架代碼。他們還會(huì)很有興趣了解您認(rèn)為在測(cè)試中哪些應(yīng)該是自動(dòng)化的 —— 如果您某些事情做了不止一遍，那么他們也會(huì)。 開(kāi)始測(cè)驗(yàn)! 現(xiàn)在是進(jìn)行小測(cè)試的時(shí)候了。讓我們看看您是否用心了。 問(wèn)題 您希望檢查一個(gè)整數(shù)的值是否為 5。通常，要這樣編寫(xiě)代碼： if ( i == 5 ) then ??{ ????// ????// do something... ????// ??} 不過(guò)，如果您對(duì)代碼進(jìn)行“手指檢查”，并且把代碼寫(xiě)成了下面這樣會(huì)出現(xiàn)什么情況呢？ if ( i = 5 ) then ??{ ????// ????// do something... ????// ??} 這個(gè)失誤是一個(gè)缺陷，但是只有在運(yùn)行時(shí)才能捕獲它 —— 可能需要相當(dāng)?shù)恼{(diào)試努力才能找到它。編譯器會(huì)輕易放過(guò)您的代碼，那么如何防止這種錯(cuò)誤發(fā)生？ 答案 實(shí)際上有兩個(gè)答案：您可以使用一種上面描述的靜態(tài)代碼分析工具，并希望它有足夠的健壯性可以捕獲這種錯(cuò)誤，也可以交換操作數(shù)以使常量位于左邊： if ( 5 == i ) then ??{ ????// ????// do something... ????// ??} 因?yàn)檫@種方法保證您可以在編譯代碼時(shí)立即捕捉到問(wèn)題，所以它是首選的技術(shù)。雖然它看上去有些笨，但是代碼可以編譯并運(yùn)行得很好。然而，當(dāng)您“手指檢查”代碼時(shí)就可以立即看到好處了： if ( 5 = i ) then ??{ ????// ????// do something... ????// ??} 可是編譯器不喜歡這樣，因?yàn)?5 不能被賦值為另一個(gè)值。這就是我們?cè)?前面 說(shuō)您應(yīng)當(dāng)將編譯器看成是您的朋友時(shí)所表達(dá)的意思。 您還可以在檢查 null 指針時(shí)使用這個(gè)技巧。看下面的代碼： if ( returnString == null ) ??{ ????// ????// do something... ????// ??} 如果您偶然將它“誤寫(xiě)”成下面這樣會(huì)發(fā)生什么呢？ if ( returnString = null ) ??{ ????// ????// do something... ????// ??} 您可能不會(huì)得到想要的結(jié)果。而改用下面的方法您會(huì)得到與我們剛描述過(guò)的同樣的“編譯器保護(hù)”： if ( null == returnString ) ??{ ????// ????// do something... ????// ??} 結(jié)束語(yǔ) 為保持簡(jiǎn)明扼要我們做了一個(gè)相當(dāng)簡(jiǎn)潔的歸納：要么現(xiàn)在去做，要么以后花 多得多 的代價(jià)去做。換句話說(shuō)，您在開(kāi)發(fā)周期的早期在測(cè)試和預(yù)防代碼缺陷上花的時(shí)間越多，您在以后節(jié)省的時(shí)間和金錢(qián)就越多。這就是防御性編碼的意義。它就是這么簡(jiǎn)單。