Какова наилучшая практика использования perl-isms (идиоматических выражений) в Perl?

пару лет назад я участвовал в написании лучших практик/стиля кодирования для нашей (довольно большой и часто использующей Perl) компании. Это сделал Комитет" старших " разработчиков Perl.

как и все, что было сделано консенсусом, у него были части, с которыми все не согласились. Да.

часть, которая терлась больше всего, была сильной рекомендацией не использовать много Перлизмов (свободно определенных как идиомы кода, отсутствующие, скажем, в C++ или Java), таких как "избегайте использования"... если только X; 'constructs".

основным обоснованием для таких правил, как этот, было то, что разработчикам без Perl было бы намного сложнее работать с базой кода Perl в противном случае. Предположение здесь я предполагаю, что жокеи кода Perl более редки в целом - и среди новых сотрудников компании - чем не-Perlers.

Мне было интересно, есть ли у SO хорошие аргументы для поддержки или отклонения этой логики... это в основном академическое любопытство на данный момент, как кодирование Perl компании стандарт окостенел и, насколько мне известно, никогда не будет пересмотрен.

P.S. Чтобы быть ясным, вопрос находится в контексте, который я отметил-ответ на все-Perl меньший магазин разработки, очевидно, громкий "использовать Perl для его максимальной возможности".

10
coding-style idiomatic-perl perl

6 ответов

какие перлизмы вы имеете в виду?

хорошо:

  • идиоматический для циклов:for(1..5) {} или for( @foo ) {}
  • скалярная контекстная оценка массивов:my $count = @items;
  • map, grep и sort: my %foo = map { $_->id => $_ } @objects;

OK если ограничено:

  • управление модификатором оператора-трейлинг if, unless и т. д.
    • ограничить задержку ошибок и ранние возвраты. die "Bad juju\n" unless $foo eq 'good juju';
    • As Шверн отметил, что другим хорошим использованием является условное присвоение значений по умолчанию:my $foo = shift; $foo = 'blarg' unless defined $foo;. Это использование, IMO, чище, чем my $foo = defined $_[0] ? shift : 'blarg';.
    • причина избежать: если вам нужно добавить дополнительные поведения к проверке или еще, у вас есть большое задание переформатирования. ИМО, хлопоты по повторению заявления (даже в хорошем редакторе) более разрушительны, чем ввод нескольких "ненужных" блоков.
  • прототипов - использовать только для создания filtery функции, такие как map. Прототипы-это подсказки компилятора, а не "прототипы" в смысле любого другого языка.
  • логические операторы-стандартизируйте, когда использовать and и or и && и ||. Весь ваш код должен быть последовательным. Лучше всего использовать политику Perl::Critic для принудительного применения.

избегать:

  • локальные переменные. Динамическая область чертовски странная, и local - это не то же самое как local где-либо еще.
  • переменные пакета. Включает плохие практики. Если вы думаете, что вам нужно глобально общее состояние, рефакторинг. Если вам все еще нужно глобально общее состояние, используйте singleton.
  • символ таблицы hackery
6

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

Если вы пишете код для людей, которые не знают языка, вы пропустите большую часть смысла использования этого языка. Я часто нахожу, что люди хотят запретить Перлизмы, потому что они отказываются узнать больше, чем они уже знают.

поскольку вы говорите, что находитесь в небольшом магазине Perl, это должно быть довольно легко спросить человека, который написал код, что это значит, если вы его не понимаете. Такие вещи должны появляться в обзорах кода и так далее. Все продолжают узнавать больше о языке, поскольку у вас есть периодические и регулярные шансы Просмотреть код. Вы не должны позволять слишком много времени протекать без других глазных яблок, смотрящих на чей-то код. Вы, конечно, не должны ждать до недели после того, как они покинут компанию.

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

Это не ограничивается Perl, либо. Это общая проблема программирования. Вы всегда должны больше узнавать о своих инструментах. В большинстве больших магазинов, которые я знаю, есть мини-буткэмпы, чтобы ускорить разработчиков на базе кода, включая любые биты хитрого кода, с которыми они могут столкнуться.

30

Я задаю себе два простых вопроса:

  • я делаю это, потому что это дьявольски умно и/или демонстрирует мои обширные знания о Perl arcana?

тогда это плохая идея. Но,

  • я делаю это, потому что это идиоматический Perl и выгоды от различных преимуществ Perl?

тогда это хорошая идея.

Я не вижу оправданной причины отклонять, скажем, интерполяцию строк только потому, что Java и C нет. unless забавно, но я думаю, что подпрограмма начинается со случайного

return undef unless <something>;

не так уж и плохо.

7

должно быть, это было, как вы говорите, несколько лет назад, потому что Дамиан Конвей "загнал рынок в угол" по стандартам Perl с Perl Лучшие Практики за последние несколько лет.

Я работал в аналогично окостенелой среде-где нам не разрешалось принимать последние лучшие практики, потому что это было бы изменение, и никто на достаточно высоком уровне в корпоративной структуре не понимал (или не мог потрудиться понять) Perl и подписаться на переезд в 21-й век.

корпорация, которая развертывает технологию и сохраняет ее, но не покупает опыт или не тренируется в доме, это прошу для неприятностей.

(Я бы предположил, что вы работаете в сильно контролируемой изменениями среде-финансовой, возможно?)

Я согласен с Брайаном об этом кстати.

2

Я бы сказал Лось убивает 99.9% Perl-измов, по соглашению, которые не должны использоваться: хакерство таблиц символов, повторная обработка объектов, общие нарушения черного ящика: обработка объектов как массивов или хэшей. Самое замечательное, что он делает все это, не принимая функциональный удар "не используя его".

Если "perl-isms", на которые вы действительно ссылаетесь, являются формой мутатора (предупредите "плохую идею", если $good_idea),unless и until тогда я не думаю, что у вас действительно есть много аргумент, потому что эти "перлизмы", похоже, не препятствуют читаемости ни для пользователей perl, ни для пользователей без perl.

1

возьмите копию эффективное Программирование Perl: способы писать лучше, более идиоматичный Perl (2-е издание), и рассматривайте это как руководство. Он содержит многие из лучших идиом и упакован с небольшими битами информации, которая заставит вас писать хороший Perl стиль Perl код, в отличие от C или Java (или что-то еще) стиль Perl код.

0