分類: 百科 常識(shí)詞典 編輯 : 常識(shí) 發(fā)布 : 08-25

閱讀 :386

對(duì)于 Pyt-on 程序，有哪些技巧/經(jīng)驗(yàn)可以讓錯(cuò)誤提早發(fā)生？動(dòng)態(tài)語言程序的一種典型錯(cuò)誤就是類型錯(cuò)誤。對(duì)于語言的類型系統(tǒng)，有靜態(tài)類型、強(qiáng)類型、弱類型的概念。其提早發(fā)現(xiàn)錯(cuò)誤的能力是遞減的：1.靜態(tài)類型系統(tǒng)，通常不必執(zhí)行程序，編輯器即可檢查出類型錯(cuò)誤，以compile time error的形式報(bào)出；2.對(duì)于強(qiáng)類型系統(tǒng)，在運(yùn)行時(shí)出現(xiàn)類型不匹配的操作，會(huì)以運(yùn)行時(shí)錯(cuò)誤的形式拋出；3.對(duì)于弱類型系統(tǒng)，很可能直到到一批詭異的內(nèi)容出現(xiàn)在你的終端/頁面上之前，你永遠(yuǎn)也不知道自己的程序出現(xiàn)錯(cuò)誤。Pyt-on屬于2的強(qiáng)類型的動(dòng)態(tài)語言，自然不期望具備compile time error。那么，能否有一些技巧，來讓(類型)錯(cuò)誤提早發(fā)生？比如說，讓首次運(yùn)行即可出錯(cuò)，而不比留到生產(chǎn)環(huán)境？6 個(gè)答案

答案 1：

1.不必執(zhí)行程序就可以發(fā)現(xiàn)的一些語法錯(cuò)誤，編輯器也能做到，比如WingIDE，vim下的插件pyflakes，還有py-ell,pylint等工具都可以進(jìn)行檢查2.善用pdb docs.pyt-on.org/library...，3. 寫測(cè)試案例，doctest,unitest等來保證程序的正確，想要大部分錯(cuò)誤都能及早檢查到就要看你的測(cè)試的覆蓋率了4. 在必要的地方使用logging,寫進(jìn)一個(gè)文件，并添加上時(shí)間5. 讓錯(cuò)誤及早發(fā)生，沈游俠在他的幻燈片中對(duì)錯(cuò)誤檢查和異常處理做了很漂亮的描述 -ttps://docs.google/fileview...補(bǔ)充說明：我不太同意李天放和董詣同學(xué)對(duì)斷言的應(yīng)用，原因我已經(jīng)回復(fù)在了董詣的評(píng)論下面，這里提出來再做一些補(bǔ)充。 - 斷言應(yīng)該用于測(cè)試和調(diào)試，用于確保一些情況永遠(yuǎn)不會(huì)發(fā)生；而易出錯(cuò)的地方應(yīng)該用拋出異常，并且通常應(yīng)該是你自己定義的異常。 - 斷言也會(huì)拋出異常，但是僅僅只拋出AssertionErrors，當(dāng)你需要精準(zhǔn)的控制捕捉異常時(shí)并不是很適用。 - pyt-on以優(yōu)化模式運(yùn)行時(shí)會(huì)忽略斷言，見docs.pyt-on.org/referenc...

答案 2：

當(dāng)你每次修好一個(gè)bug時(shí)可以試著自己回答三個(gè)問題：這個(gè)bug是怎么發(fā)生的？它屬于什么類型？有沒有某種習(xí)慣可以讓我自動(dòng)避免這個(gè)類型的bug？長(zhǎng)期這些技巧／經(jīng)驗(yàn)還是需要自己去慢慢摸索。一些比較基本的習(xí)慣包括：1. 在適當(dāng)?shù)牡胤接胊ssert確認(rèn)基本條件2. 不要習(xí)慣性的做 if c-eck － 有很多人用variable前會(huì)習(xí)慣性的寫個(gè)if， 比如：if(user != null) user.doStuff但應(yīng)該想清楚user在這個(gè)地方為什么有可能是null，假如沒有好的理由不如刪掉if，讓code早一點(diǎn)出錯(cuò)3.避免寫太長(zhǎng)太復(fù)雜的function。每個(gè)function是個(gè)邏輯單位，入口和出口都是好的c-eck point。4. 就算在強(qiáng)類型靜態(tài)系統(tǒng)下工作時(shí)，也不要過于依賴compile time tool。我見過很多java“專家”，一旦離開eclipse和findbug就變得似乎完全不會(huì)寫代碼了。這種程序員轉(zhuǎn)移到動(dòng)態(tài)語言時(shí)比較麻煩。這是我的個(gè)人看法，也不一定是對(duì)的。有空可以討論一下 ：）

答案 3：

其實(shí)像pyt-on/ruby這樣的動(dòng)態(tài)語言不必過分關(guān)心類型。應(yīng)該關(guān)注的是行為。用動(dòng)態(tài)語言的時(shí)候，程序員必須在任何時(shí)候理解自己寫的代碼。輸入什么和返回什么。如果是使用語言自身提供的API，必須先熟悉文檔，了解正在使用的接口的所有返回情況。強(qiáng)類型語言運(yùn)行時(shí)錯(cuò)誤一般就是no met-od error和type error，這些都是可以通過對(duì)輸入輸出進(jìn)行控制，和適當(dāng)?shù)膶?duì)特殊情況進(jìn)行檢測(cè)（尤其是null值）來避免的。

答案 4：

說一個(gè)我長(zhǎng)期實(shí)踐的技巧?；驹瓌t：輸入控制。coding的時(shí)候銘記強(qiáng)烈不信任任何輸入，假設(shè)我是一個(gè)function的作者，只要調(diào)用者給我的參數(shù)有一點(diǎn)點(diǎn)不符合我的期待，立即賞他個(gè)異常。至于賞他個(gè)什么樣的異常，就還需要一個(gè)決策：1、輸入錯(cuò)誤是業(yè)務(wù)相關(guān)的，例如e-il的格式錯(cuò)了，那么會(huì)給出一個(gè)詳細(xì)的自定義異常（類似E-ilAddrError）并伴隨詳細(xì)的異常說明，由調(diào)用者自行處理。2、輸入錯(cuò)誤是業(yè)務(wù)無關(guān)的，例如“大哥，我需要的是一個(gè)list，你給我個(gè)scalar是個(gè)啥意思”，這種輸入錯(cuò)誤只在開發(fā)者之間可見，跟業(yè)務(wù)、用戶完全沒關(guān)系，那么一個(gè)簡(jiǎn)單的assert即可，不需要太詳細(xì)的說明（浪費(fèi)時(shí)間），因?yàn)檫@種錯(cuò)誤很容易識(shí)別而且就是要明顯的提醒調(diào)用這個(gè)function的同伴。這樣做的好處是，所有的輸入錯(cuò)誤都會(huì)很快暴露（如果沒預(yù)料到錯(cuò)誤可能會(huì)發(fā)生并做了異常處理的話）。如果要改變參數(shù)約定，只要寫下新的assert或者自定義異常，如此這個(gè)function被不符合新約定的調(diào)用一碰就錯(cuò)，很好的滿足了提早暴露錯(cuò)誤的要求。在這種實(shí)踐下，assert不需要處理，就是要讓它錯(cuò)，所以我不同意楊昆對(duì)斷言的理解。補(bǔ)充一下，我現(xiàn)在不用assert了來干前面說的提醒同伴給正確的參數(shù)這種事情了，因?yàn)槲覍懥藗€(gè)簡(jiǎn)單的c-eck方法來干這事，能控制得更精細(xì)一點(diǎn)。

答案 5：

補(bǔ)充前面的就是，每個(gè)自模塊完全信任上層調(diào)用的輸入，自模塊不用try catc-而多assert，就是盡量吧邏輯錯(cuò)誤變成運(yùn)行時(shí)錯(cuò)誤。另外pyt-on建議的duck type這要看你設(shè)計(jì)的如何了

答案 6：

test, test ,test

下一篇:電子商務(wù)這一行怎樣入門？ 下一篇 【方向鍵 ( → )下一篇】

上一篇:“存在即合理”這句話發(fā)展至今有無新的理解？ 上一篇 【方向鍵 ( ← )上一篇】