Насколько полезный PHP CodeSniffer? Осуществление Стандартов кода в целом? [закрытый]

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

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

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

Возможно, вам лучше игнорировать CS и тратить время на фактические улучшения кода (с точки зрения дизайна,

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

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

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

function foo () {

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

function foo ()
{

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Самое замечательное в стандартах - это что у вас так много выбора.

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

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

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

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