在我们的产品中，我们有一个很大的实用程序文件，我们do在很多文件的开头都需要（带有 ）。有没有理由不把它变成一个模块？例如，不要这样做：
do '../dbi_utilities.pl';
our ($db,$user,$pw,$attr);
my $Data = DBI->connect($db,$user,$pw,$attr) or die "Could not connect to database: $DBI::errstr";
我不能这样做吗？：
use AppUtil;
my $Data = AppUtil->connect();
不这样做的唯一原因是时间。
That is, it'll take time to clean up your interface, as well as all calling apps to use the new interface.
What it'll cost you in time now will be more than made up when you start using proper tests ("make test" or "./Build test" or just "prove ...") and be able to check that your changes won't break anything before checking it in. So, by all means, convert. Just be aware that it's not a free gain.
By making your code into a module with proper refactoring, you make it easy to test. I talk about this in my "Scripts as Modules" article for The Perl Journal as well as "How a Script Becomes a Module" on Perlmonks.
Good luck,
使用do()，您每次都在加载和编译utilities.pl 文件，如果您多次do() 可能会导致问题。此外，use在编译时完成，这将使您的程序更快失败，甚至使用perl -wc.
最后，将它保存在一个包中可以保护它的命名空间，这会随着项目的增长而有所帮助。
我强烈建议将您的 utilites.pl 转换为加载了use.
用它制作一个模块将使它更加健壮。现在很多东西都非正式地相互依赖，但这些依赖关系并不是很明显。
此外，它还可以让您仅导入部分实用程序。
您可以获得所有很酷的模块内容、封装、模块特定功能等等。
但是请注意，通过使用use您的语法。为 AppUtil 命名空间创建一个对象，并调用 connect 子例程。为您的公用事业。
你也必须有 1; 在文件的末尾。
坚持另一种方法意味着您不必更改任何代码，也不必在末尾添加 1。
所有“do”、“use”和“require”导入，但其中的范围代码（命名子例程除外，因为它们不能被隐藏）。