原 名：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