原 名：Brian’s Guide to Solving Any Perl Problem
中 文: Brian 的 Perl 問題之萬能指南
作 者：brian d foy
原 文：http://www.panix.com/~comdog/brian's_guide.html
發 表：2004 七 月 20 日
翻 譯：klaus
審 校：qiang
出 處：中國 Perl協會 FPC - PerlChina.org
標題 brian的Perl問題之萬能指南
綱要 閱讀這份指南并保持明智的頭腦
描述 我的調試哲學
我相信三件事情：
這不是個人問題
別老想著是你的代碼。你可能覺得自己是個藝術家，但實際上就算是經驗豐富的大師也會寫出很多垃圾。每個人的代碼都是垃圾，我的也是你的也是。要學著去喜歡它。當你碰到問題的時候，你應該想：“噢，我寫的垃圾代碼出了點問題。”這說明你不再去責怪 Perl。不應該變成個人性的問題。
忘記你以前怎么做的。如果不是你做事的方法有點問題，你也不會來讀這個。這并不是壞事，只是到了該有點長進的時間。我們都經歷過的。
個人責任感
如果你的代碼出了問題那僅僅是——你的問題。你應該盡最大的力量自己解決。記住，每個人都有自己的代碼，每個人都有自己的問題。自己的作業自己做，在麻煩別人之前先盡自己最大的努力。如果你老老實實地按照這個指南做了所有能做的事之后，依然不能解決問題，那么你已經盡力了，應該找別人來看看。
改變你做事的方法
改正之后不要再犯同樣的錯誤。很可能是你寫代碼的方法錯了，而不是你寫的代碼錯了。改變你以前做事的方法，讓生活更容易些。不要指望Perl來習慣你，因為這是不可能的。你要習慣 Perl。它只是種語言，而不是種生活方式。
我的方法： 你用strictures編譯代碼嗎？
如果你不用 strictures，請把它打開。Perl 高手們之所以是高手，因為他們使用嚴格模式，使得他們有更多的時間解決其他問題，學新的東西，以及上載模塊倒 CPAN。
你可以使用 strict pragma 在代碼中打開 strictures
use strict;
也可以用perl的 -M開關在命令行中打開它：
perl -Mstrict script.pl
你可能會被它搞怒，但是堅持用上它幾個禮拜之后，你會寫出更好的代碼，花更少的時間來檢查低級錯誤，而且可能就不再需要讀這個指南了。
什么是warning?
Perl 會對一些有問題的結構給你警告提示。把 warning 打開，讓 Perl 來幫你。
你可以在第一行用 perl的 -w 開關打開它：
#!/usr/bin/perl -w
也可以在命令行打開warning：
perl -w script.pl
你也可以使用詞匯警告，它帶有許多有趣的特性。更多的信息參看warnings 的幫助文檔。
use warnings;
如果你不明白某個警告的意思，你可以使用 warning 的詳細模式，或者在你的代碼中使用診斷 pragma：
use diagnostics;
解決第一個問題先！
你從 Perl 中得到警告或者錯誤信息之后，先解決第一個，然后看Perl是否依舊報出其他錯誤。因為后續的錯誤很可能是由于第一個錯誤衍生而來的。
檢查錯誤信息行號之前的代碼！
Perl 在錯誤已經發生的時候才報錯，而不是在此之前。因此當 Perl 報出行號時錯誤已經發生了，而出錯的地方是在這之前。看看錯誤行號之前的代碼和表達式是否有問題。
那個變量值是你想的那樣嗎？
不要亂猜！在表達式中使用某個值的時候先檢查它是否正確。世界上最好的調試器就是 print。
print STDERR "The value is [$value]\n";
我用括號括住 $value 的原因是因為這樣我可以看見開頭和尾巴上是否有空格或者換行。
如果這個值不是標量，那么我使用 Data::Dumper 來打印這些數據結構。
require Data::Dumper;
print STDERR "The hash is ", Data::Dumper::Dumper( %hash ), "\n";
如果打印出來的結果不是你所期望的，那么移到前面幾句，再來！找到這個值最后正確的位置。也可以用 perl -d 開關打開內建的 Perl 調試器。更多信息請參考perldebug。
perl -d script.pl
你也可以使用其他調試器或者開發環境，想 ptkdb（一個基于Tk的圖形調試器）或者是 Komodo（
Active States 基于 Mozilla 的 Perl
IDE）
你用的函數是正確的嗎？
我寫 perl 程序的時間已經不短了，可我還是幾乎每天都要查 perlfunc。有些東西我就是吃不準，而有時候我太缺乏睡眠了以至于沒了常識，然后總搞不懂為什么 sprintf() 不打印到屏幕上。
你可以用perldoc命令和它的-f開關來查詢某個特定的函數。
perldoc -f function_name
如果你在使用一個模塊，查詢它的文檔，看看你是不是在用正確的方式使用它。你可以用 perldoc 查詢它的文檔。
perldoc Module::Name
你用的特殊變量是正確的嗎？
同樣，我經常去查 perlvar。不過，當我發現 Perl 快速參考這本書（The Perl Pocket Reference）更加方便之后，我就很少查perlvar了。
你用模塊版本正確嗎？
有些模塊在升級版本的時候會有不少改變。你知道你用的模塊是什么版本嗎？你可以用一個一行的 perl 語句檢查你的模塊版本：
perl -MModule::Name -le 'print Module::Name->VERSION';
如果你讀的文檔不是你機器上的本地文檔，而是像 http://www.perldoc.com或者
http://search.cpan.org 上的，那你就比較有可能碰到文檔版本差異的問題。
你用小腳本測試過了嗎？
如果你在嘗試新的東西，或者覺得某一小段代碼很奇怪，你可以寫一個最短的程序運行一下這一個片斷。這個方法把所有其他的因素都排除在外。如果測試沒有問題，那說明問題可能不在這段代碼里面。如果測試結果不對，那你大概就找到了你的問題所在。
你檢查環境了嗎？
有些東西是依賴環境變量的。你確定你的環境變量都是對的嗎？程序運行的時候用到的環境變量是你現在看到的環境變量嗎？記住有些 CGI 程序或cron 可能用到的環境變量和 shell 里的不一樣，尤其是在不同的機器上的時候。
Perl 講環境變量存儲在 %ENV 里 。如果你需要某個環境變量，就算是在測試的時候，也記住先提供一個默認值，如果它原來不存在的話。
如果還有問題，查看你的環境。
require Data::Dumper;
print STDERR Data::Dumper::Dumper( \%ENV );
你試過Google了嗎？
其他人也許碰到過和你同樣的問題。用 Google Groups（http://groups.google.com）搜索看看是不是有人在 comp.lang.perl.misc 上發過類似帖子, 沒準還能發現其他人給出的解決方法。在新聞組里問問題的人和回答問題的人的差別在于，他們使用Google Groups 的能力高底不同。
你對程序做過性能測試嗎？
如果你想知道是哪些部分讓你的程序變慢，試過性能測試嗎？可以讓Devel::Small Prof? 幫你做這件事。它可以計算 perl 執行每一行代碼的次數和花費的時間，然后打印一份漂亮的報告。
到底是那個測試沒通過？
如果你有一套測試，到底是哪個測試失敗了呢？你可以很容易的找到錯誤所在，因為每個小測試只執行一小段代碼。
如果你沒有，為什么不寫一個呢？如果你的代碼很短很短，或者只是一個一次性的程序，那我不會建議你專門寫一套測試出來。但如果不是這樣的情況，那寫一些測試代碼是很有幫助的。Test::Harness讓這件事變得太容易了，以至于你都找不到理由不做。如果你說你沒時間，那大概是因為你不用測試而在腳本除錯上浪費了太多時間。
你和小熊說話了嗎？
把你的問題大聲說出來。把它變成語言。有幾年我很愉快地和一個很優秀的程序員一起工作，他幾乎能解決任何問題。當我被什么問題堵住的時候，我總去請教他，跟他解釋我的問題。幾乎每次都是這樣的情況：我說不到第三句，就停下來，說：“噢我明白了，沒問題了。”他每次也都是這樣。
你可能需要做太多次這樣的事情，所以我推薦拿一個長毛絨玩具做為你的Perl 臨床診斷家，這樣你就不會惹怒你的同事了。我的桌子旁邊就有一只小熊，我每次都把我的問題解釋給他聽。每次當我自言自語的時候，我女朋友跟本都不會注意，她習慣了。
這問題在紙上看起來有點不一樣了嗎？
因為你老是看著電腦屏幕，所以說不定一種新的媒介可以讓你從新的角度看這個問題。把程序打印到紙上試試看。
你看 Jon Stewart 的節目嗎？
說真的。可能你不太喜歡 Jon Stewart，那換一個其他的。休息一下，停一會，讓你的大腦放松放松。當你回來的時候說不定問題忽然就很容易解決了。
你認真檢查自己了嗎？
如果到了這一步你還沒有解決的話，這說不定是個心理問題。可能你對某段代碼有特別的感情，所以不想改掉它。說不定你覺得只有你是對的，別人都錯了。當你有這種感覺的時候，你該考慮一下問題的來源—你自己。不要過于自負而不愿認清自己的錯誤。
作者
brian d foy,
COPYRIGHT
Copyright 2002, Perl Documentation Project, All Rights Reserved