＆amp;在现代Perl中是可选的，如果子例程已经预先声明，则是括号。
我注意到很多时候，人们使用的事实是，在调用Perl子例程时可以省略括号（例如，从最近的SO答案中随机引用）：
open my $fin, '<', $file;
与
一样有效open(my $fin, '<', $file);
使用第二个（无括号）版本的主要（理想情况下，技术上）原因是什么？
除了再次提及选项之外，perldoc perlsyn没有就此主题发表任何言论。
对我来说，由于我作为C开发人员的起源，总是使用括号主要是一种风格选择;但是我想知道我是否遗漏了不使用可选的无括号语法作为Perl开发人员。
P.S。我完全清楚喜欢带括号的版本的原因 - 例如the issues with indirect object notation或requirement to declare non-builtins before they are used without parenthesis，或优先级为or vs ||的问题。我对此感兴趣。
P.P.S。如果没有任何研究支持这种观点，我对答案只是说“它的风格更好”/“更具可读性”我并不感兴趣。我感兴趣的是技术原因，要么更喜欢括号遗漏，要么备份样式差异偏好（请不要将“备份”与“诉诸权威”或"argumentum ad populum"谬误混为一谈。一项显示代码速度或理解能力有所提高的研究证明：“Perl社区中的每个人都同意”或“Damien Conway建议这一点”而没有解释Damien如何支持这一点不是。）
答案 0 :(得分：15)
我认为除了样式之外，唯一真正重要的时间是根据perldoc perlsub很少使用的&subname：
&NAME; # Makes current @_ visible to called subroutine.
当然，在某些情况下（使用解析器和未来的读者），使用parens可能会更容易消除歧义，否则不使用它们可能会消除其他人的噪音;其中任何一个是必要的程度可能是我选择其中一个的主要原因。
答案 1 :(得分：9)
来自Perl::Critic::Policy::CodeLayout::ProhibitParensWithBuiltins：
Conway建议不要调用所有内置函数 参数列表周围的括号。这减少了视觉混乱和 从用户功能中消除内置函数的歧义。
Conway是 Perl Best Practices 一书的作者。
答案 2 :(得分：7)
没有技术原因可以省略括号。这纯粹是首选编码风格的问题。
答案 3 :(得分：3)
这纯粹是一种风格问题。对于Perl程序员，print "Hi\n!";比print("Hi!\n");更具可读性。使代码尽可能可读是一种很好的风格，而且 - 在其他条件相同的情况下 - 附加的符号使得阅读变得更加困难。由于内置函数不需要parens，因此有必要询问它们提供的消歧是否证明了额外的认知负荷。作为一个班级的Perl程序员已经走到了“不”的一边，部分得益于Damien Conway对规则的正式化。
Conway还建议保留内置插件无需将其与用户定义的功能区分开来，但我认为这种说法不那么具有说服力。更确切地说，许多内置插件被设计为在没有parens的情况下自然地读取，因此应该以这种方式使用。看到defined($x)或len($y)会让Perl程序员抽搐，但只会看到croak($z)。
请注意，将Perl编写为C语言的重点是 bad 样式。写Perl就好像它是Perl一样。