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

Во-первых, я поддерживаю 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, чтобы узнать, может ли он вам помочь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 function foo () { 

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

 function foo () { 

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