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

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

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

Часть, которая потерпела неудачу больше всего, была сильной рекомендацией НЕ использовать много Perlisms (слабо обозначенных как идиомы кода, отсутствующие, например С++ или Java), такие как "Избегайте использования"... если X; конструкты".

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

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

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

Ответы

Ответ 1

Что это за перлизмы?

Хорошо:

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

ОК, если он ограничен:

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

Избегайте:

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

return undef unless <something>;

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

Ответ 6

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