3

我写了很多相当小的 perl 脚本。它们的范围从 10 行到 1,000 行不等，但中值大小可能只有 100 行左右。当我开始编写脚本时，我倾向于将事情分解成块并创建子例程。发生的事情是我最终编写了很多看起来像的脚本

sub mkdir {
    ... directory testing logic ...
    ... mkdir ...
}
sub createFile {
    ... check for directory ...
    ... try and create the file, exit if failure ...
}
sub somethingElse {
    .... do stuff with the file that was created ...
}
sub yetAnotherThing {
    ... do even more stuff ...
}

&mkdir;
&createFile;
&somethingElse
&yetAnotherThing

这对我来说一直很奇怪。我喜欢它最终是模块化的，我可以轻松地注释掉某些任务，但我不确定它是否是构建此类小程序的最佳方式。

我的问题是：

  1. 有没有人有任何具体的理由为什么我不应该以这种方式构建脚本？我没有看到很多其他人这样做，所以感觉好像我做错了什么。
  2. 谁能建议一种更好的方法来构建较小的脚本？我是否应该完全跳过创建子例程并按顺序写出我希望脚本执行的操作？这是我想太多了吗？:)

谢谢！

4

2 回答 2

3

您所做的是正确的，并且被认为是编程中的良好做法。这称为功能分解——您将任务分解为更小的功能。

事实上，在行业中，往往会发生的情况是人们开始编写大量内联代码，然后当它变得难以管理时，开始重构代码以变得更像你正在做的事情。

以 CPAN 中的项目为例。它们中的大多数都分解为小功能。实际上，它们中的大部分都被进一步分解为相关功能的模块。

这是一个很好的第一步。下一步是在代码中编写.pm相关函数的文件use。之后的下一步是编写面向对象的代码。

于 2013-10-25T06:55:08.067 回答
2

您的方法对我来说看起来很明智，而且我确实在其他地方看到过类似的脚本。

你的一些方法现在可能是你已经养成的一种舒适的习惯，值得重新思考和刻意尝试更高层次的东西。首先，您的脚本中有多少包含几乎相同的 5 个目录和文件处理逻辑子例程？您很有可能：

  • 齐心协力寻找可以缩短或不需要这些例程的 CPAN 模块。

  • 编写您自己的模块以包含脚本之间共享的代码。

这两件事都会让你变得更有效率，而且你似乎正在编写很多这样的脚本，这值得追求。

于 2013-10-25T06:58:01.590 回答