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

Я балуюсь идеей настройки PHP CodeSniffer на нашем сервере непрерывной интеграции, чтобы улучшить качество нашей кодовой базы. После прочтения документации я очень взволнован идеей нормализации и обеспечения соблюдения наших стандартов кодирования. Тем не менее, я остаюсь в недоумении по поводу фактического улучшения нашего продукта. Мне хорошо известно, что сниффер обнаруживает только нарушения определенного стандарта кодирования, но какие преимущества дает чистая, последовательная кодовая база? Стоит ли дополнительных усилий по рефакторингу проекта с более чем 100 тысячами строк кода для соответствия стандарту PEAR?

Для тех, кто не знаком с PHP CodeSniffer или запахом кода в целом, вот пример вывода:

ФАЙЛ: /path/to/code/myfile.php
ОБНАРУЖЕНА ОШИБКА 5, ВЛИЯЮЩАЯ НА 2 СТРОКИ
-
2 | ОШИБКА | Отсутствует комментарий к файлу документа
20 | ОШИБКА | Ключевые слова PHP должны быть в нижнем регистре; ожидалось "ложь", но обнаружено "ЛОЖЬ"
47 | ОШИБКА | Линия имеет неправильный отступ; ожидается 4 места, но найдено 1
51 | ОШИБКА | Отсутствует комментарий к функции doc
88 | ОШИБКА | Линия имеет неправильный отступ; ожидается 9 мест, но найдено 6

Строго говоря, пользователь / клиент не заметит никакой разницы в продукте, который был переработан для соответствия стандартам, но мне интересно, есть ли другие скрытые преимущества.

Прямо сейчас наш код ни в коем случае не является небрежным, и мы стараемся следовать нашим собственным личным стандартам, которые по большей части основаны на Стандарты кодирования Pear, но натренированный глаз может заметить различия.

Поэтому мой вопрос в том, насколько они улучшают качество продукта. Какие скрытые выгоды это принесло?

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


person Mike B    schedule 11.06.2009    source источник
comment
Меня никогда не перестает удивлять, как я продолжаю находить, казалось бы, хорошие, информативные вопросы о SO, которые закрываются как неконструктивные.   -  person Thomas F.    schedule 02.06.2015


Ответы (8)


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

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

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

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

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

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

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

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

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

person Greg Sherwood    schedule 12.05.2011
comment
Большое спасибо Грегу за то, что поделился с нами своей историей. Я очень сомневался, начинать ли использовать этот инструмент или нет. Сейчас точно воспользуюсь. - person Danilo Radenovic; 11.02.2013

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

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

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

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

person molf    schedule 11.06.2009
comment
Я хотел бы отметить, что phpcs поставляется с набором снифферов, специально адресованных фактическому код пахнет, и его довольно легко расширить для обнаружения запахов, которые вы определяете сами. - person Potherca; 13.09.2012

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

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

В стандартах замечательно то, что у вас есть из чего выбирать.

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

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

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

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

person Jeff Dickey    schedule 28.07.2010
comment
Я обнаружил, что исключение файлов, созданных до моей работы, лучше всего влияет на мое психическое здоровье. В отношении новых классов / методов просто отметьте в DocBlock «Да, это закодировано в соответствии с этим стандартом». - person David J Eddy; 03.10.2013

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

Последовательные скобки, отступы улучшают код. Не хватает места после запятых при вызове функции? Вероятно, можно простить, но это ОШИБКА согласно CodeSniffer.

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

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

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

person Kornel    schedule 12.06.2009
comment
Я считаю, что стоит отметить, что все возражения в вашем ответе на самом деле являются возражениями против определенного стандарта кодирования (предположительно Zend или PEAR), а не против самого CodeSniffer. Я обнаружил, что очень полезно создать новый стандарт для каждого проекта, выбирая и выбирая среди общих сниффов и написав свои собственные (очень специфичные для проекта) сниффы. Это действительно единственный разумный подход, который я вижу для больших проектов с унаследованным кодом (что у вас нет возможности переписать с нуля), и наборы правил XML + исключения значительно упростили управление этим. - person Peter; 05.10.2011
comment
Полностью согласен с Питером. Конечно, базовые стандарты CS не будут соответствовать вашим потребностям из коробки. Вы должны потратить немного времени, по крайней мере, на настройку наборов правил. После этого следует написание собственных правил, так как для этого нужно немного больше навыков. - person Tom Desp; 02.02.2012

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

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

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

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

person DavidWinterbottom    schedule 26.08.2009

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

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

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

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

person Tchule    schedule 01.06.2010
comment
Есть ли способ передать его из командной строки (argv) в команду $_GET или $_POST? - person Talvi Watia; 09.07.2010

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

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

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

person Sven    schedule 07.06.2010

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

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

Например, я фанат

function foo () {

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

function foo ()
{

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

person nategood    schedule 11.06.2009