Рубрика «Code Style» - 3

в 8:28, , рубрики: Code Style, mojolicious, perl

Хочу описать стиль программирования на языке Perl, к которому я стремлюсь и который в основном перенял от современного web-фреймворка Mojolicious, но наверное много где еще применяется подобный. Мне кажется выработать правильный стиль кодинга — очень важно.

Пример 1:
Методы в одну строку.
Если обращение к каждому аргументу функции происходит лишь один раз, и порядок применения их в коде соответствует порядку переданных аргументов, то предлагается извлекать их с помощью стандартной функции shift, которая если вызывается без аргументов, по-умолчанию работает с массивом @_, в котором хранятся все переданные аргументы функции, выталкивает первый аргумент из массива и возвращает его.

sub node { shift->tree->[0] }
#
sub parse { shift->_delegate(parse => shift) }
#
sub _tag { shift->new->tree(shift)->xml(shift) }

Пример 2:
Сначала извлекаем первый параметр, имя класса например, все остальные аргументы передаем другой функции и пусть она их обрабатывает.

sub tree { shift->_delegate(tree => @_) } 
# т.е. может превратиться в это _delegate(tree => [], deep => 5) или это _delegate(tree => [], 5, 0) 
sub log { shift->emit('message', lc shift, @_) }

Пример 3:
Тоже для метода в одну строчку.
Здесь происходит обращение к одному и тому же аргументу целых 3 раза, потому для доступа к аргументу используется прямое обращение к элементу массива аргументов $_[0].

sub _instance { ref $_[0] ? $_[0] : $_[0]->singleton }

Читать полностью »

Существуют некоторые соглашения касаемые структуры класса, и того, в каком порядке должны располагаться его члены.
Например, правила которые использует StyleCop, возможно, в вашей компании есть свои собственные.
Поддерживать структуру вручную довольно тяжело, скучно и отнимает много времени, особенно когда в классе довольно большое количество свойств, полей, методов и.т.д.
В этом посте речь пойдет о том, как с помощью Resharper автоматизировать этот процесс.
Читать полностью »

При офомлении исходного текста все мы пользуемся каким либо Code Convention. Хорошо, когда внутри компании есть документ, который описывает эти соглашения. Если нет, то приходится пользоваться каким-то общеизвестным, который нам кажется стандартным. Хотя, конечно, понятие его стандартности весьма относительно. Лучше все таки иметь такой документ внутри компании, что бы не было разнологласий в команде.

Один из вопросов, который возникает при формировании такого документа — правая граница в исходном тексте. Раньше было принято использовать правую границу 80 (а то и 76) символов. Но сейчас мониторы широкие. Может быть можно и не ограничивать? Или все таки надо ограничивать? Вот, например, и совсем недавно, в этой статье данный вопрос вызвал довольно большую полемику. Под катом мое видение этого вопроса + опрос.
Читать полностью »

Очередной спор о стиле, красоте и компактности кода занял слишком много времени, в связи с чем и был отправлен на разрешение широкой аудитории StackOverflow. Это помогло, и спор решился, но в комментариях мне намекнули, что я пришел не по адресу:

Stack Exchange's "codereview" site is the new hotness for this sort of question.

Оказывается, больше года назад в застенках Area 51 был рожден вопросник Code Review, призванный делать код лучше.

Читать полностью »

В этой статье я хочу поделиться опытом использования одной полезной утилиты, позволяющей автоматизировать сборку и анализ качества кода. Речь пойдет о Yasca — свободно распространяемом ПО, представляющем собой небольшой PHP движок и набор утилит для выполнения анализа Java, С++ или PHP кода, включающего в себя PMD, JLint и RATS. Сама интеграция выполнения этих утилит осуществляется путем разработки небольших плагинов, на языке PHP. О процессе разработки такого плагина и пойдет речь далее.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js