Что делает Perl-код пригодным для обслуживания?

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

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

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

Ответ 1

Что делает код Perl неподъемным? Практически все, что делает любую другую программу незаменимой. Предполагая, что для выполнения четко определенной задачи используется не что иное, как короткий script, выполните следующие действия:

Глобальные переменные
Отсутствие разделения проблем: Монолитные сценарии
НЕ использовать самодокументирующие идентификаторы (имена переменных и имена методов). Например. вы должны знать, какой переменной целью является его имя. $c Плохо. $count лучше. $token_count хорошо.
- Идентификаторы заклинаний. Размер программы больше не имеет особого значения.
- Подпрограмма или метод под названием doWork ничего не говорят
- Упростите поиск источника символов из другого пакета. Либо используйте явный префикс пакета, либо явно импортируйте каждый символ, используемый через use MyModule qw(list of imports).
Perl-конкретны:
- Чрезмерная зависимость от коротких сокращений и скрытых встроенных переменных
- Нарушение прототипов подпрограмм
- не использовать strict и не использовать warnings
Повторное использование колеса, а не использование установленных библиотек
Не использовать согласованный стиль отступов
Не использовать горизонтальное и вертикальное пустое пространство для руководства читателем.

и т.д. и т.д. и т.д.

В принципе, если вы считаете, что Perl -f>@+?*<.-&'_:$#/%!, и вы стремитесь писать подобные вещи в производственном коде, тогда, да, вы будут проблемы.

Люди склонны путать вещи, которые программисты Perl делают для развлечения (например, JAPHs, golf и т.д.), с какими хорошими программами Perl должны выглядеть.

Я все еще не понимаю, как они могут разделить в своем уме код, написанный для IOCCC от поддерживаемого C.

Ответ 2

Я предлагаю:

Не слишком увлекайтесь Perl. Если вы начнете играть в гольф с кодом, это приведет к более сложному считыванию кода. Код, который вы пишете, должен быть читабельным и четким, чем нужно, чтобы быть умным.
Документируйте код. Если это модуль, добавьте POD, описывающий типичное использование и методы. Если это программа, добавьте POD для описания параметров командной строки и типичного использования. Если есть волосатый алгоритм, запишите его и укажите ссылки (URL), если это возможно.
Используйте форму регулярных выражений /.../x и документируйте их. Не все хорошо понимают регулярные выражения.
Знайте, что такое связь, и плюсы/минусы связи высокой/низкой.
Знайте, что такое сплоченность, и плюсы/минусы высокой/низкой сплоченности.
Используйте модули соответствующим образом. Хорошая четко определенная, содержательная концепция делает отличный модуль. Цель использования повторного использования таких модулей. Не используйте модули просто для уменьшения размера монолитной программы.
Напишите модульные тесты для вашего кода. Хороший набор тестов не только позволит вам доказать, что ваш код работает сегодня, но и завтра. Это также позволит вам сделать более смелые изменения в будущем, с уверенностью, что вы не нарушаете старые приложения. Если вы разобьете вещи, значит, ваш набор тестов недостаточно широк.

Но в целом, тот факт, что вы достаточно заботитесь об обслуживании, чтобы задать вопрос об этом, говорит мне, что вы уже в хорошем месте и думаете правильно.

Ответ 3

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

Ответ 4

Что делает поддерживаемый код Perl?

По крайней мере:

use strict;
use warnings;

См. perldoc perlstyle для некоторых общих рекомендаций, которые облегчат чтение, понимание и поддержку ваших программ.

Ответ 5

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

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

У белого пространства есть много смысла/использования, когда мы говорим о читаемости, а не все из них широко используются, но наиболее полезны:

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

Это пространство вдвойне важно в Perl из-за преобладания символов линейного шума даже в коде Perl лучшего стиля.

Я нахожу $myHashRef->{$keys1[$i]}{$keys3{$k}} менее читаемым в 2 часа ночи в середине чрезвычайной ситуации производства по сравнению с интервалом: $myHashRef->{ $keys1[$i] }->{ $keys3{$k} }.

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

Частичный, но ОЧЕНЬ важный частный случай этого - это, конечно, регулярные выражения. Разница была проиллюстрирована до смерти во всех основных материалах, которые я помню (PBP, книга RegEx O'Reilly и т.д.), Поэтому я не буду удлинять это сообщение даже дальше, если кто-то не попросит примеры в комментариях.
Правильный и равномерный отступ. D'о. Очевидно. Тем не менее, я вижу слишком много кода на 100% нечитабельно из-за дрянного отступов и даже менее читаемого, когда половина кода была отступом с помощью TAB лицом, редактор которого использовал 4 символьные вкладки, а другой - человеком, редактор которого использовал 8 символов TAB. Просто установите ваш кровавый редактор, чтобы делать мягкие (например, эмулированные пространства) TAB, и не делайте других несчастными.
Пустые строки вокруг логически отдельных единиц кода (оба блока и просто наборы строк). Вы можете написать 10000 строк Java-программы в 1000 строк хорошего Perl. Теперь не чувствуйте себя как Бенедикт Арнольд, если вы добавите 100-200 пустых строк к этим 1000, чтобы сделать вещи более читаемыми.
Разделение uber-long выражений на несколько строк, за которыми следуют...
Правильное вертикальное выравнивание. Свидетельствуйте разницу между:
```
if ($some_variable > 11 && ($some_other_bigexpression < $another_variable || $my_flag eq "Y") && $this_is_too_bloody_wide == 1 && $ace > my_func() && $another_answer == 42 && $pi == 3) {
```
и
```
if ($some_variable > 11 && ($some_other_bigexpression < $another_variable || 
    $my_flag eq "Y") && $this_is_too_bloody_wide == 1 && $ace > my_func()
    && $another_answer == 42 && $pi == 3) {
```
и
```
if (   $some_variable > 11
    && ($some_other_bigexpression < $another_variable || $my_flag eq "Y")
    && $this_is_too_bloody_wide == 1
    && $ace > my_func()
    && $another_answer == 42
    && $pi == 3) {
```
Лично я предпочитаю исправлять вертикальное выравнивание еще одним шагом, выравнивая LHS и RHS (это особенно читаемо в случае длинных SQL-запросов, но также и в самом коде Perl, как длинных условных выражениях, так и многих строках назначений и инициализации хеша/массива):
```
if (   $some_variable               >  11
    && ($some_other_bigexpression   <  $another_variable || $my_flag eq "Y")
    && $this_is_too_bloody_wide    ==  1
    && $ace                         >  my_func()
    && $another_answer             ==  42
    && $pi                         ==  3  ) {
```
В качестве побочного примечания, в некоторых случаях код может быть сделан еще более удобочитаемым/поддерживаемым, не имея таких длинных выражений в первую очередь. Например. если содержимое блока if(){} равно return, то выполнение нескольких операторов if/unless, каждый из которых имеет обратный блок, может быть лучше.

Ответ 6

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

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

другие будут ссылаться на использование коротких форм, таких как @_, $! и т.д. все это легко устранить... я не заинтересован в том, чтобы сделать perl похожим на java.

потенциал всех этих причуд и перлизмов заключается в том, что кодовые базы, написанные на этом языке, часто являются краткими и компактными. я бы предпочел читать десять строк perl, чем сто строк java.

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

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

Ответ 7

Я бы сказал, что модели упаковки/объекта, которые отражаются в структуре каталогов для файлов .pm. Для моего докторанта я написал довольно много кода Perl, который я повторно использую впоследствии. Это было для автоматического генератора диаграмм LaTeX.

Ответ 8

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

Верно, что вы обычно не должны быть слишком умны с действительно плотными утверждениями a la return [email protected];#% и т.п., но неплохо умеете использовать операторы переименования, такие как map и grep и list- контекст возвращает от подобных split и подобных операторов, чтобы писать код в функциональном стиле может внести позитивный вклад в ремонтопригодность. У моего последнего работодателя у нас также были некоторые эффектные функции хэш-манипуляции, которые работали аналогичным образом (hashmap и hashgrep, хотя технически мы только кормили их списками даже по размеру). Например:

# Look for all the servers, and return them in a pipe-separated string
# (because we want this for some lame reason or another)
return join '|', 
       sort
       hashmap {$a =~ /^server_/ ? $b : +()} 
       %configuration_hash;

См. также Perl верхнего порядка, http://hop.perl.plover.com - хорошее использование метапрограммирования может сделать определяющие задачи более согласованными и читаемыми, если вы можете сохранить метапрограммируя себя от мешания.