Советую использовать Perl::Tidy и Perl::Critic.
Вырабатывается единый стиль.
А изучая варнинги Perl::Critic узнаешь много нового о лучших практиках написания кода.
У меня это все в виде плагина к виму, по хоткею исходник форматируется и код прогоняется через статический анализатор.
Также удобен хук при коммите — форматирует код и не дает закоммитить, если стат. анализатор выдает критические варнинги.

Perl lives forever!

parserpro 1 сен 2014 в 11:18

Тут не стиль форматирования описан, а критику такое КМК не по зубам.

zdm001 1 сен 2014 в 12:08

Статья начинается словами про стиль программирования — именно это заставило меня отписаться.

Perl::Critic даже тут мог бы помочь в некоторых примерах.

Пример 14: use constants — надо использовать Const::Fast или Readonly;

Вообще Perl::Critic позволяет оптимизировать подходы именно к написанию кода, а не форматированию.

Для форматирования — Perl::Tidy.

Все это совместно приводит к вырабатыванию единого стиля написания программ. Для команды — вещь необходимая.

flaresun 2 сен 2014 в 16:01

Плагином к vim'у не поделитесь? :)

zdm001 2 сен 2014 в 16:25

Рад бы, но не могу.
Плагин использует код нашего perl фреймоврка, надо весь код выкладывать, а он не готов к публикации.
Позже все будет на спане, когда точно — не знаю.

НЛО прилетело и опубликовало эту надпись здесь

dmrt 2 сен 2014 в 08:18

Можете рассказать, что там интересного, раз принимали участие? Ваше отношение?

НЛО прилетело и опубликовало эту надпись здесь

flaresun 2 сен 2014 в 16:14

Вот говорю я коллегам, что perl — это не страшно, perl — это не сложно, perl — это читабельно/понимабельно, perl — это не обфускатор. И что я теперь скажу, если они прочтут эту статью? :-D

dmrt 2 сен 2014 в 16:40

я ожидал совсем другого эффекта, все же просто :) C-подобный язык же с парой своих фишек.

flaresun 2 сен 2014 в 16:35

А вообще по теме… Соглашаться или не соглашать со стилем программирования — тут у каждого свой подход. А вот стиль изложения мыслей довольно сложный, путанный. Где-то описание к примерам похоже именно на описание, или пояснение, а где-то это просто заголовок.

используется такая конструкция условия, если первое истина, а второе ложь, чтобы не выполнялось второе условие, если первое ложь.

Там собраны некоторые функции, в методе import, через вышеописанную функцию monkey_patch добавляются.

Понимать сложно…

И если часть примеров вроде бы нацелены на улучшение читабельности кода, то остальные совершенно противоположны этой цели :)

dmrt 2 сен 2014 в 16:44

Согласен что комментарии я наверно плохо написал, не получается пока лучше излагать, в голове вертятся слова понятные только мне :)
А примеры все нацелены на улучшение читабельности и поддержки кода. Можете привести пример, где наоборот?

flaresun 4 сен 2014 в 06:19

Вообще я не планировал обсуждать непосредственно код, потому и написал, что у каждого свой подход. Но пример привести могу.

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

Методы в одну строку.
sub node { shift->tree->[0] }

* само собой при условии, что они достаточно короткие и рядом есть аналогичные по длине

Но такой вариант записи вряд ли улучшит читаемость/понимаемость кода.

Срез массива.

$_ eq $child ? last : $i++ for @$parent[$i .. $#$parent];

Здесь конечно не метод, но тоже некий блок, да ещё с условием в краткой форме. По мне так гораздо читабельнее было бы записать этот фрагмент как метод в одну строку (из примера выше). Да и при необходимости выполнить более одной операции в результате сравнения такой вариант придётся переписывать, а не просто добавить новое действие. Тут на мой взгляд и ухудшение читаемости и закладывание необходимости большего объёма работ для любой небольшой правки кода…

flaresun 4 сен 2014 в 11:50

Положу здесь, вдруг кому пригодится :)
20 most important Perl Best Practices

withlove 16 сен 2014 в 07:56

Хоть сам использую Mojolicious и при всем уважении к автору, его стиль не рекомендовал бы, он подходит лишь в определенных случаях.
Одно дело внутренности Mojolicious, который автор по сути единолично только и разрабатывает (хотя сообщество и большое). А другое дело веб-приложение, которое не только вы программируете (или потом будет поддерживать кто-то другой). Тем более не стоит ориентироваться на исходный код Mojo::DOM например…

sub find { $_[0]->_collect(@{$_[0]->_css->select($_[1])}) }

Потом будет трудно вспомнить что в $_[0], а что в $_[1]. А кому-то другом еще труднее. И в одну строчку тяжелее читать.

$_ eq $child ? last : $i++ for @$parent[$i .. $#$parent];

flaresun уже написал, что это только затрудняет читаемость.

if ($params->[$i] eq $name) { splice @$params, $i, 2 }
else { $i += 2 }

Здесь даже тернарный оператор нагляднее:

($params->[$i] eq $name)
  ? splice @$params, $i, 2
  : $i += 2;

и т.п.

То есть я не в качестве критики, а как альтернативный взгляд именно с позиции чтения кода и его поддержки.

Книга Perl Best Practics и Perl::Tidy / Perl::Critic очень помогают в этом плане.

Советую еще посмотреть код модулей представленный в Task::Kensho, а не ограничиваться исходным кодом Mojolicious.

dmrt 16 сен 2014 в 19:36

Спасибо за советы. Изучу тогда другие модули для сравнения и напишу по ним тоже пожалуй пост.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий