Каков наилучший способ использования перлизмов (идиоматических выражений) в Perl? - PullRequest
10 голосов
/ 22 января 2010

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

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

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

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

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

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

Ответы [ 6 ]

30 голосов
/ 22 января 2010

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

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

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

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

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

7 голосов
/ 22 января 2010

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

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

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

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

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

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

return undef unless <something>;

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

6 голосов
/ 22 января 2010

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

Хорошо:

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

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

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

Избегайте:

  • Локальные переменные. Динамическая область действия чертовски странна, и local отличается от local где-либо еще.
  • Переменные пакета. Включает плохие практики. Если вы думаете, что вам нужно глобально общее состояние, рефакторинг. Если вам все еще нужно глобально общее состояние, используйте синглтон.
  • Таблица символов взлома
2 голосов
/ 23 января 2010

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

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

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

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

Кстати, я согласен с Брайаном .

1 голос
/ 22 января 2010

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

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

0 голосов
/ 19 августа 2010

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

...