Comments 25
«Пример 13:
Метод базового класса, который необходимо переопределить в родительском.»
Вроде странно звучит.
Метод базового класса, который необходимо переопределить в родительском.»
Вроде странно звучит.
Советую использовать Perl::Tidy и Perl::Critic.
Вырабатывается единый стиль.
А изучая варнинги Perl::Critic узнаешь много нового о лучших практиках написания кода.
У меня это все в виде плагина к виму, по хоткею исходник форматируется и код прогоняется через статический анализатор.
Также удобен хук при коммите — форматирует код и не дает закоммитить, если стат. анализатор выдает критические варнинги.
Perl lives forever!
Вырабатывается единый стиль.
А изучая варнинги Perl::Critic узнаешь много нового о лучших практиках написания кода.
У меня это все в виде плагина к виму, по хоткею исходник форматируется и код прогоняется через статический анализатор.
Также удобен хук при коммите — форматирует код и не дает закоммитить, если стат. анализатор выдает критические варнинги.
Perl lives forever!
Тут не стиль форматирования описан, а критику такое КМК не по зубам.
Статья начинается словами про стиль программирования — именно это заставило меня отписаться.
Perl::Critic даже тут мог бы помочь в некоторых примерах.
Пример 14: use constants — надо использовать Const::Fast или Readonly;
Вообще Perl::Critic позволяет оптимизировать подходы именно к написанию кода, а не форматированию.
Для форматирования — Perl::Tidy.
Все это совместно приводит к вырабатыванию единого стиля написания программ. Для команды — вещь необходимая.
Perl::Critic даже тут мог бы помочь в некоторых примерах.
Пример 14: use constants — надо использовать Const::Fast или Readonly;
Вообще Perl::Critic позволяет оптимизировать подходы именно к написанию кода, а не форматированию.
Для форматирования — Perl::Tidy.
Все это совместно приводит к вырабатыванию единого стиля написания программ. Для команды — вещь необходимая.
Плагином к vim'у не поделитесь? :)
UFO just landed and posted this here
Вот говорю я коллегам, что perl — это не страшно, perl — это не сложно, perl — это читабельно/понимабельно, perl — это не обфускатор. И что я теперь скажу, если они прочтут эту статью? :-D
А вообще по теме… Соглашаться или не соглашать со стилем программирования — тут у каждого свой подход. А вот стиль изложения мыслей довольно сложный, путанный. Где-то описание к примерам похоже именно на описание, или пояснение, а где-то это просто заголовок.
Понимать сложно…
И если часть примеров вроде бы нацелены на улучшение читабельности кода, то остальные совершенно противоположны этой цели :)
используется такая конструкция условия, если первое истина, а второе ложь, чтобы не выполнялось второе условие, если первое ложь.
Там собраны некоторые функции, в методе import, через вышеописанную функцию monkey_patch добавляются.
Понимать сложно…
И если часть примеров вроде бы нацелены на улучшение читабельности кода, то остальные совершенно противоположны этой цели :)
Согласен что комментарии я наверно плохо написал, не получается пока лучше излагать, в голове вертятся слова понятные только мне :)
А примеры все нацелены на улучшение читабельности и поддержки кода. Можете привести пример, где наоборот?
А примеры все нацелены на улучшение читабельности и поддержки кода. Можете привести пример, где наоборот?
Вообще я не планировал обсуждать непосредственно код, потому и написал, что у каждого свой подход. Но пример привести могу.
Например я согласен, что такой вариант может улучшить читаемость. Я и сам не люблю подобные короткие блоки разносить на пять строк.
Но такой вариант записи вряд ли улучшит читаемость/понимаемость кода.
Здесь конечно не метод, но тоже некий блок, да ещё с условием в краткой форме. По мне так гораздо читабельнее было бы записать этот фрагмент как метод в одну строку (из примера выше). Да и при необходимости выполнить более одной операции в результате сравнения такой вариант придётся переписывать, а не просто добавить новое действие. Тут на мой взгляд и ухудшение читаемости и закладывание необходимости большего объёма работ для любой небольшой правки кода…
Например я согласен, что такой вариант может улучшить читаемость. Я и сам не люблю подобные короткие блоки разносить на пять строк.
Методы в одну строку.* само собой при условии, что они достаточно короткие и рядом есть аналогичные по длине
sub node { shift->tree->[0] }
Но такой вариант записи вряд ли улучшит читаемость/понимаемость кода.
Срез массива.
$_ eq $child ? last : $i++ for @$parent[$i .. $#$parent];
Здесь конечно не метод, но тоже некий блок, да ещё с условием в краткой форме. По мне так гораздо читабельнее было бы записать этот фрагмент как метод в одну строку (из примера выше). Да и при необходимости выполнить более одной операции в результате сравнения такой вариант придётся переписывать, а не просто добавить новое действие. Тут на мой взгляд и ухудшение читаемости и закладывание необходимости большего объёма работ для любой небольшой правки кода…
Хоть сам использую Mojolicious и при всем уважении к автору, его стиль не рекомендовал бы, он подходит лишь в определенных случаях.
Одно дело внутренности Mojolicious, который автор по сути единолично только и разрабатывает (хотя сообщество и большое). А другое дело веб-приложение, которое не только вы программируете (или потом будет поддерживать кто-то другой). Тем более не стоит ориентироваться на исходный код Mojo::DOM например…
Потом будет трудно вспомнить что в $_[0], а что в $_[1]. А кому-то другом еще труднее. И в одну строчку тяжелее читать.
flaresun уже написал, что это только затрудняет читаемость.
Здесь даже тернарный оператор нагляднее:
и т.п.
То есть я не в качестве критики, а как альтернативный взгляд именно с позиции чтения кода и его поддержки.
Книга Perl Best Practics и Perl::Tidy / Perl::Critic очень помогают в этом плане.
Советую еще посмотреть код модулей представленный в Task::Kensho, а не ограничиваться исходным кодом 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.
Mojolicious Perl Style