2009-06-11 11 views
52

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

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

FILE: /path/to/code/myfile.php
НАЙДЕНО 5 ERROR (S) АФФЕКТИВНОСТЬ 2 ЛИНИИ
-
2 | ОШИБКА | Отсутствует файл doc comment
20 | ОШИБКА | PHP-ключевые слова должны быть строчными; ожидаемый «false», но найден «FALSE»
47 | ОШИБКА | Строка не имеет отступов правильно; ожидаемое 4 место, но найдено 1
51 | ОШИБКА | Отсутствует функция doc comment
88 | ОШИБКА | Строка не имеет отступов правильно; ожидается 9 пространств, но нашло 6

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

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

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

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

+7

Он никогда не перестает удивлять меня, как я продолжаю находить, казалось бы, хорошие, информативные вопросы о СО, которые закрываются «как не конструктивные». –

ответ

32

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

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

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

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

+0

Я хотел бы указать, что phpcs поставляется с комплектом sniff * специфически * адресацией фактического [запаха кода] (http://en.wikipedia.org/wiki/Code_smells) и его можно легко расширить, чтобы обнаружить запахи вы определяете себя. – Potherca

0

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

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

Например, я поклонник формата против стандарта PEAR на

function foo() { 

..

function foo() 
{ 

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

6

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

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

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

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

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

+9

Я считаю, что стоит отметить, что все возражения в вашем ответе действительно возражают против конкретного стандарта кодирования (предположительно, Zend или PEAR), а не самого CodeSniffer. Я нашел * очень полезным для создания нового стандарта для каждого проекта, путем выбора и выбора среди «общих» нюхов и написания собственных (очень специфичных для проекта) нюхов. Это действительно единственный разумный подход, который я могу видеть для больших проектов с устаревшим кодом (которого у вас нет роскоши переписывания с нуля), а XML-правила + исключения сделали это намного проще в управлении. – Peter

+1

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

3

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

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

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

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

3

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

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

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

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

+0

Удивительный! Спасибо Tchule –

+0

Любой способ передать его из командной строки (argv) в команду '$ _GET' или' $ _POST'? –

1

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

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

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

11

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

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

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

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

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

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

Я просто wrote a new blog post об этом.

+0

Отличные очки, спасибо Джефф. –

+0

Я нашел исключение файлов, которые предшествуют моей работе, чтобы быть лучшим для моего психического здоровья. О новых классах/методах просто отметим в DocBlock 'Hay, это закодировано для этого стандарта'. –

98

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

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

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

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

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

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

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

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

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

+5

Большое спасибо Грегу за то, что разделили свою историю с нами. Я очень сомневался в том, начать ли использовать этот инструмент или нет. Теперь я буду использовать его точно. –