Brian 的 Perl 问题之万能指南

标题

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（ ActiveStates 基于 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::SmallProf 帮你做这件事。它可以计算 perl 执行每一行代码的次数和花费的时间，然后打印一份漂亮的报告。

到底是那个测试没通过？

如果你有一套测试，到底是哪个测试失败了呢？你可以很容易的找到错误所在，因为每个小测试只执行一小段代码。

如果你没有，为什么不写一个呢？如果你的代码很短很短，或者只是一个一次性的程序，那我不会建议你专门写一套测试出来。但如果不是这样的情况，那写一些测试代码是很有帮助的。Test::Harness让这件事变得太容易了，以至于你都找不到理由不做。如果你说你没时间，那大概是因为你不用测试而在脚本除错上浪费了太多时间。

你和小熊说话了吗？

把你的问题大声说出来。把它变成语言。有几年我很愉快地和一个很优秀的程序员一起工作，他几乎能解决任何问题。当我被什么问题堵住的时候，我总去请教他，跟他解释我的问题。几乎每次都是这样的情况：我说不到第三句，就停下来，说：“噢我明白了，没问题了。”他每次也都是这样。

你可能需要做太多次这样的事情，所以我推荐拿一个长毛绒玩具做为你的Perl 临床诊断家，这样你就不会惹怒你的同事了。我的桌子旁边就有一只小熊，我每次都把我的问题解释给他听。每次当我自言自语的时候，我女朋友跟本都不会注意，她习惯了。

这问题在纸上看起来有点不一样了吗？

因为你老是看着电脑屏幕，所以说不定一种新的媒介可以让你从新的角度看这个问题。把程序打印到纸上试试看。

你看 Jon Stewart 的节目吗？

说真的。可能你不太喜欢 Jon Stewart，那换一个其他的。休息一下，停一会，让你的大脑放松放松。当你回来的时候说不定问题忽然就很容易解决了。

你认真检查自己了吗？

如果到了这一步你还没有解决的话，这说不定是个心理问题。可能你对某段代码有特别的感情，所以不想改掉它。说不定你觉得只有你是对的，别人都错了。当你有这种感觉的时候，你该考虑一下问题的来源—你自己。不要过于自负而不愿认清自己的错误。