为什么我应该使用 或<>而不是 在 Perl 中?
引用自 Perl::Critic::Policy::InputOutput: :禁止ExplicitStdin
Perl 有一个名为 *ARGV 的有用的神奇文件句柄,它检查命令行,如果有任何参数,则将其打开并作为文件读取。如果没有参数,*ARGV 的行为类似于 *STDIN。如果您想创建一个从 STDIN 读取的程序,这种行为几乎总是您想要的。这通常以以下两种等效形式之一编写:
while (
) { # ...对每个输入行执行一些操作... } # 或者,等价: 而 (<>) { # ...对每个输入行执行一些操作... }
- 它是“只是一种约定”还是有一些不使用
的充分理由?
我觉得
使我的代码的意图比使用 <>
或
更清晰。
我的代码流程是这样的
my @inp = <STDIN>;
my $len = $inp[0];
...
for(my $i = 0; $i < ($len + 0); $i++) {
my @temp = split (' ', $inp[$i]);
...
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
这是因为使用
将使用户能够指定要读取的文件作为参数,或者在不指定参数的情况下将内容通过管道传输到 stdin 中。如果您使用
,则只有管道可以工作。当然,由您决定是否认为人们希望能够将文件指定为命令行参数,但这是很多程序支持的东西,因此可能值得考虑。
It's because using
<ARGV>
will enable users to either specify files to read from as arguments, or pipe stuff into stdin while specifying no arguments. If you use<STDIN>
, only piping will work.Of course it's up to you to decide if you think people would like to be able to specify files as command line arguments, but it's something a lot of programs support so it might be worth thinking about.
您可以使用能够完成您想做的事情的那个。有关
ARGV
文件句柄的说明,请参阅 perlvar。ARGV
还会读取您在命令行上指定的文件名。也许您想要该功能,也许您不需要。而且,您不必按照 Perl::Critic 所说的去做。其中许多政策都是一小部分人的意见。如果您只想显式地从 STDIN 读取,那么您需要这样做。编写 Critic 政策的人不会告诉你需要做什么。如果没有其应用背景,问这样的问题基本上是毫无意义的。一般规则只是一般性的,在讨论具体情况时就会失效。
我不确定为什么您认为 STDIN 的意图更清晰,因为您没有告诉我们您的意图。代码几乎从不说明问题,因为我们倾向于编写解决方案而不是陈述问题。该解决方案可能不是正确的。
就您而言,我认为这段代码更清晰,因为它是用 Perl 编写的,而不是您正在使用的 C 方言:)
You use the one that does what you want to do. See perlvar for an explanation of the
ARGV
filehandle.ARGV
also reads from filenames you specify on the command line. Maybe you want that feature, maybe you don't.And, you don't have to do what Perl::Critic says. Many of those policies are the opinions of a small group of people. If you only want to read from STDIN explicitly, that's what you need to do. The people writing the Critic policies aren't there to state what you need to do. Asking any question like this is mostly pointless without the context of its application. General rules are merely general, and break down when talking about specific cases.
I'm not sure why you think your intent is clearer with STDIN because you didn't tell us your intent. Code almost never speaks for itself because we tend to code the solution instead of stating the problem. The solution might not be the right one.
In your case, I think this code is more clear because it's written in Perl instead of the C dialect you're using :)