歡迎來到 常識詞典網 ， 一個專業的常識知識學習網站！
[ Ctrl + D 鍵 ]收藏本站
答案 1：
1.不必執行程序就可以發現的一些語法錯誤，編輯器也能做到，比如WingIDE，vim下的插件pyflakes，還有py-ell,pylint等工具都可以進行檢查2.善用pdb docs.pyt-on.org/library...，3. 寫測試案例，doctest,unitest等來保證程序的正確，想要大部分錯誤都能及早檢查到就要看你的測試的覆蓋率了4. 在必要的地方使用logging,寫進一個文件，并添加上時間5. 讓錯誤及早發生，沈游俠在他的幻燈片中對錯誤檢查和異常處理做了很漂亮的描述 -ttps://docs.google/fileview...補充說明：我不太同意李天放和董詣同學對斷言的應用，原因我已經回復在了董詣的評論下面，這里提出來再做一些補充。 - 斷言應該用于測試和調試，用于確保一些情況永遠不會發生；而易出錯的地方應該用拋出異常，并且通常應該是你自己定義的異常。 - 斷言也會拋出異常，但是僅僅只拋出AssertionErrors，當你需要精準的控制捕捉異常時并不是很適用。 - pyt-on以優化模式運行時會忽略斷言，見docs.pyt-on.org/referenc...答案 2：
當你每次修好一個bug時可以試著自己回答三個問題：這個bug是怎么發生的？它屬于什么類型？有沒有某種習慣可以讓我自動避免這個類型的bug？長期這些技巧／經驗還是需要自己去慢慢摸索。一些比較基本的習慣包括：1. 在適當的地方用assert確認基本條件2. 不要習慣性的做 if c-eck － 有很多人用variable前會習慣性的寫個if， 比如：if(user != null) user.doStuff但應該想清楚user在這個地方為什么有可能是null，假如沒有好的理由不如刪掉if，讓code早一點出錯3.避免寫太長太復雜的function。每個function是個邏輯單位，入口和出口都是好的c-eck point。4. 就算在強類型靜態系統下工作時，也不要過于依賴compile time tool。我見過很多java“專家”，一旦離開eclipse和findbug就變得似乎完全不會寫代碼了。這種程序員轉移到動態語言時比較麻煩。這是我的個人看法，也不一定是對的。有空可以討論一下 ：）答案 3：
其實像pyt-on/ruby這樣的動態語言不必過分關心類型。應該關注的是行為。用動態語言的時候，程序員必須在任何時候理解自己寫的代碼。輸入什么和返回什么。如果是使用語言自身提供的API，必須先熟悉文檔，了解正在使用的接口的所有返回情況。強類型語言運行時錯誤一般就是no met-od error和type error，這些都是可以通過對輸入輸出進行控制，和適當的對特殊情況進行檢測（尤其是null值）來避免的。答案 4：
說一個我長期實踐的技巧。基本原則：輸入控制。coding的時候銘記強烈不信任任何輸入，假設我是一個function的作者，只要調用者給我的參數有一點點不符合我的期待，立即賞他個異常。至于賞他個什么樣的異常，就還需要一個決策：1、輸入錯誤是業務相關的，例如e-il的格式錯了，那么會給出一個詳細的自定義異常（類似E-ilAddrError）并伴隨詳細的異常說明，由調用者自行處理。2、輸入錯誤是業務無關的，例如“大哥，我需要的是一個list，你給我個scalar是個啥意思”，這種輸入錯誤只在開發者之間可見，跟業務、用戶完全沒關系，那么一個簡單的assert即可，不需要太詳細的說明（浪費時間），因為這種錯誤很容易識別而且就是要明顯的提醒調用這個function的同伴。這樣做的好處是，所有的輸入錯誤都會很快暴露（如果沒預料到錯誤可能會發生并做了異常處理的話）。如果要改變參數約定，只要寫下新的assert或者自定義異常，如此這個function被不符合新約定的調用一碰就錯，很好的滿足了提早暴露錯誤的要求。在這種實踐下，assert不需要處理，就是要讓它錯，所以我不同意楊昆對斷言的理解。補充一下，我現在不用assert了來干前面說的提醒同伴給正確的參數這種事情了，因為我寫了個簡單的c-eck方法來干這事，能控制得更精細一點。答案 5：
補充前面的就是，每個自模塊完全信任上層調用的輸入，自模塊不用try catc-而多assert，就是盡量吧邏輯錯誤變成運行時錯誤。另外pyt-on建議的duck type這要看你設計的如何了答案 6：
test, test ,test下一篇:電子商務這一行怎樣入門？ 下一篇 【方向鍵 ( → )下一篇】
上一篇:“存在即合理”這句話發展至今有無新的理解？ 上一篇 【方向鍵 ( ← )上一篇】
快搜
