Насколько полезен PHP CodeSniffer? Обеспечение соблюдения норм стандартов в целом?

Ответ 1

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

Я работал над несколькими крупными проектами CMS. У первого была куча кода за ним и относительно небольшая команда разработчиков. У нас не было никаких стандартов. Но у нас не было реальных проблем. Команда была маленькой и долгое время оставалась вместе. Мы привыкли друг к другу.

Затем мы построили новую CMS. Мы начали работать с несколькими разработчиками. Затем я был частью команды из двух разработчиков. И снова стандарты кодирования не вызвали у нас никаких проблем. Я и другие разработчики пришли с одного и того же фона и уже установили некоторые рекомендации, которыми мы руководствовались. Мы тогда не нуждались в PHPCS.

Но эта команда выросла разработчиком за один раз и в итоге достигла 12 штатных разработчиков, и немало пришло и ушло. Некоторые пришли из старой CMS, а некоторые прибыли из-за пределов компании. У всех были разные фоны и другой подход к развитию. Было очевидно, кто написал какой код, потому что стили были настолько разными. Всякий раз, когда вы работали над чем-то сложным, вам сначала нужно приспособиться к их стилю, потому что это было просто не так, как вы привыкли видеть код. Это как чтение Шекспира в первый раз. Вам нужно привыкнуть к нему, прежде чем вы сможете читать в своем естественном темпе.

Для разработчиков это дополнительное время, чтобы остановить и выяснить другой стиль кодирования - это просто потраченное впустую время. Это шанс для идеи ускользнуть, пока вы увязли с шагом, отступом и скобой. В конце концов, все это не имеет значения. Но позвольте мне сказать вам, они очень важны, если они заставляют разработчиков нарушать их поток. Таким образом, нам нужен был способ заставить их уйти с пути и позволить разработчикам делать то, что они делают лучше всего.

В то же время мы намного больше копались в JavaScript. Новый язык, в котором стиль вообще был выброшен в окно. Код был скопирован/вставлен из примеров сайтов и спрессован вместе. Изучая разработку сложного кода на новом языке, имело смысл найти способ сделать наш JS похожим на наш PHP. Мы можем свести его к минимуму позже, но нам нужно было быстро переключаться между языками, чтобы сохранить поток.

Итак, для этого родился PHP_CodeSniffer. Это помогает разработчикам работать с одним и тем же стилем кодирования, чтобы форматирование и другие проблемы с пламенем были полностью устранены. Это позволяет вам относиться к вашему JS, как к вашему PHP. Я использую его для обнаружения специфических для продукта запахов, таких как нетранслируемые строки или разработчиков, которые не используют наш правильный код включения класса. Я также использую его для специфических для языка запахов, чтобы убедиться, что запятая JS, которая убивает IE, не оставлена. Вы можете использовать его так, как хотите. Он поставляется с кучами обнюхиваний, которые легко объединяются, используя файл правил XML. Вы также можете написать свой собственный. Вы можете интегрировать сторонние инструменты, чтобы сделать его универсальным магазином для анализа статического кода. Вы можете быть так же серьезно относитесь к стандартам и запахам кода, как вам нравится.

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

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

Ответ 2

Согласование стилей кодирования - хорошая идея, потому что это помогает разработчикам не отвлекаться на код, написанный в другом стиле при работе над кодом, который они не пишут. Это сделает вашу базу кода более поверхностной. Это здорово, если вы можете автоматизировать его, но, как правило, нет необходимости проходить большую длину, чтобы соответствовать (если только текущий стиль не страшен). Если у вас уже есть достаточно хороший стандарт, придерживайтесь его.

Запах кода - это нечто другое: это (набор) симптомов, которые могут указывать на более глубокую проблему с кодом. Примерами являются циклическая сложность, длинные имена методов, большие классы, неописательные имена, дублирующий код и т.д. Это обычно гораздо более проблематично, так как это может серьезно повредить ремонтопригодность вашего кода. Вы должны обязательно решить эти проблемы.

PHP CodeSniffer, по-видимому, в основном разработан для проверки соглашений стилей, а не от запаха кода. Если вы можете использовать его, чтобы обеспечить соблюдение соглашений стилей, отлично. Но будьте осторожны, что это не сделает вашу базу кода существенно лучше. Вы захотите выполнить ручные обзоры, чтобы выполнить это.

Если вы хотите использовать его, чтобы проверить, соответствует ли вы вашему текущему стандарту, что кажется возможным, см. ответ на вопрос "Я не согласен с вашими стандартами кодирования! Могу ли я сделать PHP_CodeSniffer своим собственным?" в своем FAQ.

Ответ 3

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

Как сказал Грейс Хоппер и/или Эндрю Таненбаум,

Замечательная вещь о стандартах что у вас так много на выбор.

Аналогично, это почти всегда плохая идея и торговля; создать свой собственный стандарт кодирования; создание одного достаточно всеобъемлющего, чтобы охватить весь ваш код, трудно, и, что более важно, не будет любить следующего человека, чтобы поддерживать ваш код, который попытается "улучшить" ваш стандарт, чтобы он соответствовал его долговременному, стиль кодирования. Принятие соответствующего внешнего стандарта, будь то Zend или PEAR или Kohana или JoeBobBriggsAndHisFifthCousin, позволяет вам сосредоточиться на контенте, а не на форматировании. Еще лучше, такие инструменты, как PHP CodeSniffer, либо поддерживают стандарт "свежий из олова", либо те, кто ушел раньше, почти наверняка реализовали поддержку в качестве дополнения.

Стандарты смешивания кодирования с существующим кодом, не записанным на этот стандарт, дадут вам пригонки, если вы не примете два простых дополнительных правила.

Исключить файлы, которые принятие стандарта кодирования из проверяются через --ignore командная строка вариант или эквивалент настройки конфигурационного файла. Но когда вы модифицируете любую часть исходный файл, обновите весь файл до соответствовать выбранному вами стандарту.

Я просто написал новое сообщение в блоге об этом.

Ответ 4

Существует множество случаев, требующих человеческого суждения, а CodeSniffer - нет.

Согласованные скобки, отступы улучшают код. Недостаточно места после запятых в вызове функции? Наверное, можно простить, но это ERROR в соответствии с CodeSniffer.

IMHO существует слишком много ошибок, сообщаемых CS. Даже проекты, которые, как представляется, имеют четкий код, могут легко запускать тысячи проблем с CS. Быстро становится утомительным и почти невозможно разрешить все эти проблемы, особенно когда это сочетание реальных проблем и обсессивно-компульсивной глупости - оба одинаково часто обозначаются как ОШИБКИ.

Вам может быть лучше игнорировать CS и тратить время на фактические улучшения кода (с точки зрения дизайна, алгоритмов), а не просто полностью поверхностные пробелы и изменения комментариев (для функции 1-строчной isAlpha действительно нужны 8 строк комментарии? Да, если вы спросите CS).

Слишком легко превратиться в инструмент торсионной полировки.

Ответ 5

Это определенно хорошо. Мы запускаем нашу версию с помощью SVN-крючка, чтобы весь код должен был передать стандарт дома (модификация из PEAR), прежде чем он сможет быть совершен (это было одно из лучших решений, которое я когда-либо делал).

Конечно, это лучше всего подходит для нового проекта, где нет загрузки устаревшего кода для преобразования в новый стандарт. Один из способов этого - изменить привязку SVN до фиксации, чтобы запускать новые дополнения к идентификатору кода и игнорировать изменения. Вы можете сделать это, добавив строку:

$SVNLOOK changed "$REPOS" -t "$TXN" | grep "^A.*\.php " > /dev/null || exit 0

Это приведет к выходу из hook script, если для анализа не существует нового кода PHP. Следовательно, все новые файлы должны будут соответствовать стандарту, и вы можете привести устаревший код в соответствие со стандартом в свое время.

Ответ 6

Обратите внимание, что если вы используете Eclipse или Zend IDE, вы можете воспользоваться автоматическими инструментами, которые делают использование стандарта менее дорогостоящим. Вы также можете использовать инструмент непрерывной интеграции, такой как Hudson или PHPUndercontrol.

• PDT - классный редактор для PHP
• PDT-Tools - это некоторые плагины для PDT с автоматическим инструментом форматирования.
• DTLK (Dynamic Toolkit Library) может использоваться для запуска некоторых внешних скриптов для проверки ваших файлов.

Вы также можете посмотреть PHP Checkstyle, который, как мне кажется, проще настроить (отказ от ответственности: я работал над ним)

Некоторые другие инструменты перечислены на странице "документации" на веб-сайте.

Ответ 7

CodeSniffer - отличная вещь для реализации, но вы должны знать, как ее использовать. Если вы не должны соблюдать данный стандарт кодирования, потому что вы отправляете свою работу на какой-то внешний проект, вы можете полностью определить свои собственные стандарты кодирования.

PHP CodeSniffer должен сделать это очень легко для вас, потому что уже есть много единых кодов, которые вы можете включить в свое собственное стандартное определение кодирования и не должны писать их с нуля. Изучая возможности существующих Codesniffers, вы можете в конечном итоге написать расширение для существующего нюха или одного нюха, если вы почувствуете необходимость.

Если вы хотите начать с CodeSniffer, первым шагом будет захват набора нюансов, которые полностью напоминают ваши текущие стандарты кодирования, и проверьте полученные ошибки и предупреждения. Не применяйте один из предопределенных стандартов, так как это, скорее всего, приведет к слишком большому количеству ошибок при слишком небольшом выигрыше, если исправлено. Например, если вы не используете PHPDoc для генерации документации, было бы бесполезно выполнять все ошибки, связанные с кодом, в отношении отсутствующих тегов и комментариев PHPDoc.

Ответ 8

Предоставляете ли вы пакеты PEAR для публичного распространения через PEAR/PECL? Если это так, вы, вероятно, захотите придерживаться соглашений PEAR.

В противном случае я не вижу, чтобы это стоило большого рефакторинга. Самое главное, соглашаясь на стандарт кодирования для вашей команды... не обязательно должен быть стандартом PEAR... просто убедитесь, что существует стандартная конвенция.

Например, я поклонник

function foo () {

по сравнению со стандартом PEAR.

function foo ()
{

В нижней строке, не беспокойтесь о том, чтобы соответствовать их стандарту, если это будет тонна работы, особенно если вы не ставите пакеты на PECL.