В чем причина использования вызовов подпрограмм без ограничений в Perl?

и является необязательным в современном Perl, как и круглые скобки, если подпрограмма была предварительно определена.

Я замечаю, что много раз люди используют тот факт, что вы можете опустить скобки при вызове подпрограмм Perl (например, случайное цитирование из недавнего ответа SO):

open my $fin, '<', $file;

столь же справедливо, как

open(my $fin, '<', $file);

Каковы основные (в идеале, технические) причины использования второй (без скобок) версии?

perldoc perlsyn ничего не говорит по этой теме, кроме как снова упоминает опциональность.

Для меня всегда использование круглых скобок в основном является стилистическим выбором из-за моего происхождения как разработчика C; но Я хотел бы знать, не хватает ли я чего-то, если не использовать необязательный синтаксис без кавычек в качестве разработчика Perl.

P.S. Я хорошо знаю причины, чтобы предпочесть версию с круглыми скобками - например. проблемы с опознаванием косвенных объектов или требование объявлять нестронные до того, как они будут использоваться без круглых скобок или проблемы с приоритетом visavi or vs ||. Меня интересует обратное.

P.P.S. Я не очень заинтересован в ответах, просто заявляя "это лучший стиль" / "более читаемый" без каких-либо исследований, поддерживающих мнение. Меня интересуют либо технические причины, чтобы предпочесть исключение в скобках, либо резервные копии стилистических отличительных предпочтений (просьба не путать "резервное копирование" с "призывом к власти" или "argumentum ad populum" Заблуждения. Исследование, показывающее улучшение скорости или понимания кода, является доказательством. "Все в коммьюнити Perl согласны" или "Дамиен Конвей предлагает это", не объясняя, как Дамиен это не поддерживает).

Ответ 1

Я думаю, что единственный раз, когда это действительно имеет значение, кроме стиля, используется для редко используемого &subname, который согласно perldoc perlsub:

&NAME;     # Makes current @_ visible to called subroutine.

Конечно, использование parens может в некоторых случаях упростить устранение неоднозначности (как для парсера, так и для будущего читателя), а также не использовать их, чтобы удалить шум в других; степень, в которой это необходимо, вероятно, является основной причиной, по которой я когда-либо выбирал тот или иной.

Ответ 2

От Perl::Critic::Policy::CodeLayout::ProhibitParensWithBuiltins:

Конвей предлагает, чтобы все встроенные функции вызывались без круглые скобки вокруг списка аргументов. Это уменьшает визуальный беспорядок и устраняет неоднозначность встроенных функций из пользовательских функций.

Конвей является автором книги Perl Best Practices.

Ответ 3

Нет никаких технических причин для исключения скобок. Это исключительно вопрос предпочтительного стиля кодирования.

Ответ 4

Это чисто вопрос стиля. Для программиста Perl print "Hi\n!"; более читаем, чем print("Hi!\n");. Это хороший стиль, чтобы сделать код максимально читаемым, а при прочих равных - дополнительные символы усложняют чтение. Так как встроенным устройствам не нужны парнеры, имеет смысл спросить, оправдывает ли их неоднозначность, оправдывая дополнительную когнитивную нагрузку. И программисты Perl как класс сошли на сторону "нет", чему частично помогла формализация Дамиеном Конвеем правила.

Конвей также предполагает, что сохранение встроенных паролей помогает отличить их от пользовательских функций, но я считаю, что этот аргумент менее убедителен. Правильнее сказать, что многие встроенные модули предназначены для естественного чтения без парнеров, поэтому их следует использовать таким образом. Увидев defined($x) или len($y), программисты Perl дергаются, но не более, чем видя croak($z).

Обратите внимание, что запись Perl, как если бы это была C, была явно плохой стиль. Напишите Perl, как будто это Perl.