0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Теги: php, code review, return, codesniffer, хук после каждого коммита, phpstorm, phpcs, psr1, psr2, pear, zend, symfony2, yoda conditions, avoidyodaconditionssniff.php</p>
1
<p>Теги: php, code review, return, codesniffer, хук после каждого коммита, phpstorm, phpcs, psr1, psr2, pear, zend, symfony2, yoda conditions, avoidyodaconditionssniff.php</p>
2
<p>Сейчас большинство команд разработки принимает на вооружение стандарты кодирования и организовывает процедуры следования им. Самый лучший способ следить за соблюдением принятых стандартов, конечно же, это<strong>code review</strong>. Но постоянное возвращение кода из-за незамеченного тобой отступления от правил кодирования, к примеру, отсутствия отступа перед оператором<strong>return</strong>, не добавляет популярности данной процедуре. Чтобы уменьшить объём подобных небрежностей, для PHP-программистов существует инструмент<a><strong>CodeSniffer</strong></a>.</p>
2
<p>Сейчас большинство команд разработки принимает на вооружение стандарты кодирования и организовывает процедуры следования им. Самый лучший способ следить за соблюдением принятых стандартов, конечно же, это<strong>code review</strong>. Но постоянное возвращение кода из-за незамеченного тобой отступления от правил кодирования, к примеру, отсутствия отступа перед оператором<strong>return</strong>, не добавляет популярности данной процедуре. Чтобы уменьшить объём подобных небрежностей, для PHP-программистов существует инструмент<a><strong>CodeSniffer</strong></a>.</p>
3
<p>Чтобы не пропустить очевидных нарушений стандарта кодирования, можно добавить запуск<strong>CodeSniffer’а</strong><a>хуком</a>после каждого коммита. Для тех, кто использует<strong>PHPStorm</strong>, есть возможность использовать<a>готовый плагин</a>, который будет автоматически запускать проверку кода и выполнять подсветку мест, которые не прошли проверку, сразу в редакторе.</p>
3
<p>Чтобы не пропустить очевидных нарушений стандарта кодирования, можно добавить запуск<strong>CodeSniffer’а</strong><a>хуком</a>после каждого коммита. Для тех, кто использует<strong>PHPStorm</strong>, есть возможность использовать<a>готовый плагин</a>, который будет автоматически запускать проверку кода и выполнять подсветку мест, которые не прошли проверку, сразу в редакторе.</p>
4
<p>Сам по себе<strong>PHPCS</strong>уже из коробки содержит множество существующих стандартов -<strong>PSR1, PSR2, PEAR, Zend</strong>. При этом самым интересным в использовании<strong>CodeSniffer</strong>является возможность его расширения под собственные внутренние правила. Поэтому на<strong>GitHub</strong>легко можно найти множество готовых расширений, позволяющих использовать кастомные правила, например, реализация стандартов, принятая разработчиками на<a><strong>Symfony2</strong></a>.</p>
4
<p>Сам по себе<strong>PHPCS</strong>уже из коробки содержит множество существующих стандартов -<strong>PSR1, PSR2, PEAR, Zend</strong>. При этом самым интересным в использовании<strong>CodeSniffer</strong>является возможность его расширения под собственные внутренние правила. Поэтому на<strong>GitHub</strong>легко можно найти множество готовых расширений, позволяющих использовать кастомные правила, например, реализация стандартов, принятая разработчиками на<a><strong>Symfony2</strong></a>.</p>
5
<p>Одна из самых распространенных причин, по которой разработчики отказываются использовать<strong>CodeSniffer</strong>в повседневной работе, - наличие собственных правил, реализация которых отсутствует в сборке. Но очень хорошей практикой для вас как для разработчиков является возможность самим реализовать эти правила, которые приняты только внутри вашей команды, чтобы в будущем вся команда пользовалась ими. Разработчики подготовили очень качественный<a>мануал</a>, по которому вы сможете начать разрабатывать "сниффы", то есть правила, проверяющие следование определённому правилу принятого стандарта.</p>
5
<p>Одна из самых распространенных причин, по которой разработчики отказываются использовать<strong>CodeSniffer</strong>в повседневной работе, - наличие собственных правил, реализация которых отсутствует в сборке. Но очень хорошей практикой для вас как для разработчиков является возможность самим реализовать эти правила, которые приняты только внутри вашей команды, чтобы в будущем вся команда пользовалась ими. Разработчики подготовили очень качественный<a>мануал</a>, по которому вы сможете начать разрабатывать "сниффы", то есть правила, проверяющие следование определённому правилу принятого стандарта.</p>
6
<p>Например, в нашей компании для пресечения непрекращающегося холивара на тему использования<strong>Yoda conditions</strong>принято правило, которое запрещает такие конструкции. Здесь можно посмотреть готовое расширение, которое позволяет сканировать ваш код на наличие таких условий:<a>AvoidYodaConditionsSniff.php</a>.</p>
6
<p>Например, в нашей компании для пресечения непрекращающегося холивара на тему использования<strong>Yoda conditions</strong>принято правило, которое запрещает такие конструкции. Здесь можно посмотреть готовое расширение, которое позволяет сканировать ваш код на наличие таких условий:<a>AvoidYodaConditionsSniff.php</a>.</p>
7
<p><em>Есть вопрос? Напишите в комментариях!</em></p>
7
<p><em>Есть вопрос? Напишите в комментариях!</em></p>
8
8