Pull to refresh

Comments 25

«Пример 13:
Метод базового класса, который необходимо переопределить в родительском.»
Вроде странно звучит.
Пример 15 — quotemeta не аналог?
Пример 16 — нехватает вертикального выравнивания
"// — операдор "
опечаточка
спасибо, поправил
да, просто тут не получилось это сделать.
Не, quotemeta экранизирует символы не относящиеся к набору слов /[A-Za-z_0-9]/
Переопределить в дочернем надо, ошибся, спасибо.
Советую использовать Perl::Tidy и Perl::Critic.
Вырабатывается единый стиль.
А изучая варнинги Perl::Critic узнаешь много нового о лучших практиках написания кода.
У меня это все в виде плагина к виму, по хоткею исходник форматируется и код прогоняется через статический анализатор.
Также удобен хук при коммите — форматирует код и не дает закоммитить, если стат. анализатор выдает критические варнинги.

Perl lives forever!
Тут не стиль форматирования описан, а критику такое КМК не по зубам.
Статья начинается словами про стиль программирования — именно это заставило меня отписаться.

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

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

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

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

Все это совместно приводит к вырабатыванию единого стиля написания программ. Для команды — вещь необходимая.
Плагином к vim'у не поделитесь? :)
Рад бы, но не могу.
Плагин использует код нашего perl фреймоврка, надо весь код выкладывать, а он не готов к публикации.
Позже все будет на спане, когда точно — не знаю.
UFO just landed and posted this here
Можете рассказать, что там интересного, раз принимали участие? Ваше отношение?
UFO just landed and posted this here
Вот говорю я коллегам, что perl — это не страшно, perl — это не сложно, perl — это читабельно/понимабельно, perl — это не обфускатор. И что я теперь скажу, если они прочтут эту статью? :-D

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


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

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


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

Например я согласен, что такой вариант может улучшить читаемость. Я и сам не люблю подобные короткие блоки разносить на пять строк.
Методы в одну строку.
sub node { shift->tree->[0] }
* само собой при условии, что они достаточно короткие и рядом есть аналогичные по длине


Но такой вариант записи вряд ли улучшит читаемость/понимаемость кода.
Срез массива.
$_ eq $child ? last : $i++ for @$parent[$i .. $#$parent];

Здесь конечно не метод, но тоже некий блок, да ещё с условием в краткой форме. По мне так гораздо читабельнее было бы записать этот фрагмент как метод в одну строку (из примера выше). Да и при необходимости выполнить более одной операции в результате сравнения такой вариант придётся переписывать, а не просто добавить новое действие. Тут на мой взгляд и ухудшение читаемости и закладывание необходимости большего объёма работ для любой небольшой правки кода…
Хоть сам использую 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.
Спасибо за советы. Изучу тогда другие модули для сравнения и напишу по ним тоже пожалуй пост.
Sign up to leave a comment.

Articles