Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 55
Во-первых, если человек использует способ оформления кода отличный от вашего, то не стоит его называть говнокодером.
Во-вторых, все эти стандарты, не более чем условность, а в случае с phpcs это в двойне условность, потому что никто не гарантирует соответствие его самого каким-то стандартам. К примеру, пользовался им в плоть до версии 1.3 после обновления, на которую код, который был валидным в 1.2 вдруг стал не валидным.
>«самые умные» просто используют git commit --no-verify, потому что сейчас им не до ошибок
Самые умные создают алиас для этой команды и вообще забывают об этом недоразумении, и имхо правильно делают.
По-моему лучше, периодически выделять время на чистку кода, чем задалбывать всех каждый раз, при комите.
Во-вторых, все эти стандарты, не более чем условность, а в случае с phpcs это в двойне условность, потому что никто не гарантирует соответствие его самого каким-то стандартам. К примеру, пользовался им в плоть до версии 1.3 после обновления, на которую код, который был валидным в 1.2 вдруг стал не валидным.
>«самые умные» просто используют git commit --no-verify, потому что сейчас им не до ошибок
Самые умные создают алиас для этой команды и вообще забывают об этом недоразумении, и имхо правильно делают.
По-моему лучше, периодически выделять время на чистку кода, чем задалбывать всех каждый раз, при комите.
>По-моему лучше, периодически выделять время на чистку кода, чем задалбывать всех каждый раз, при комите.
К сожалению, такой подход обычно порождает «синдром разбитых окон», о чем хорошо написано в книге «Программист-прагматик» Соблюдать конвенцию — не слишком сложно, и стоит просто приучится делать это на автомате.
К сожалению, такой подход обычно порождает «синдром разбитых окон», о чем хорошо написано в книге «Программист-прагматик» Соблюдать конвенцию — не слишком сложно, и стоит просто приучится делать это на автомате.
>в плоть до версии 1.3 после обновления, на которую код, который был валидным в 1.2 вдруг стал не валидным.
Ну это нормально произошло ужесточение стандарта в следующей версии.
стандартизация идет шаг за шагом
мы в свое время вводили стандарты кодирования в крупном проекте там тоже все было более сурово с каждым нововведением.
Стандарты нужны и соблюдать и надо перманентно для того чтоб была высокая читаемость кода.
Сколько у вас людей работает одновременно над одним проектом?
Ну это нормально произошло ужесточение стандарта в следующей версии.
стандартизация идет шаг за шагом
мы в свое время вводили стандарты кодирования в крупном проекте там тоже все было более сурово с каждым нововведением.
Стандарты нужны и соблюдать и надо перманентно для того чтоб была высокая читаемость кода.
Сколько у вас людей работает одновременно над одним проектом?
Я использовал стандарт Zend. Там ситуация немного другая, автора снифера и зенды не поделили лицензии и послали друг друга на 3 буквы, в итоге поддержка этого стандарта, является номинальной. В одном проекте использовал анонимные функции, так и не нашел способа их объявления чтоб снивер не ругался, потому что стандарт написан под первый ZF1, а он под PHP 5.2.
Кстати что произойдет, если кто-то добавит в код, к примеру, трит из PHP5.4 или еще что-нибудь новенькое? Он наверное долго будет пытается его закомитить с проверкой на стандарты.
Кстати что произойдет, если кто-то добавит в код, к примеру, трит из PHP5.4 или еще что-нибудь новенькое? Он наверное долго будет пытается его закомитить с проверкой на стандарты.
Во-первых, если человек использует способ оформления кода отличный от вашего, то не стоит его называть говнокодером.
В проекте может быть только один способ форматирования, так что если разработчик в команде использует своё форматирование, отличное от принятого в проекте, то да — он говнокодер.
что вообще за манера лепить слово говнокодер где не попади?!
В моем понимании это человек, который:
— пишет код, который работает в зависимости от фазы луны;
— не обрабатывает ошибки;
— пишет не семантичный код ( когда метод getObject возвращает к примеру число).
Если вы будете за каждый пробел, человека называть говнокодером, то ваша команда долго не протянет, либо вам устроят темную.
В моем понимании это человек, который:
— пишет код, который работает в зависимости от фазы луны;
— не обрабатывает ошибки;
— пишет не семантичный код ( когда метод getObject возвращает к примеру число).
Если вы будете за каждый пробел, человека называть говнокодером, то ваша команда долго не протянет, либо вам устроят темную.
Возьмем, к примеру, меня, я предпочитаю зендовый стандарт, при этом я не могу сказать что человек использующий, к примеру пировский стандарт как вы выразились «срет на меня». У меня есть проекты, написанные в разных стилях, и если мне приходиться там что-то разгребать то не, потому что они оформлены в не моем стиле, а потому что код кривой.
Имхо хороший не зависит от какогото стандарта, количества коментариев, это код который интуетивно понятен и логичен. Ну нравится человеку открывать фигурную скобочку на новой/тойже строке, помоему это не большая проблема, и уж точно неповод для открытых конфликтов
Имхо хороший не зависит от какогото стандарта, количества коментариев, это код который интуетивно понятен и логичен. Ну нравится человеку открывать фигурную скобочку на новой/тойже строке, помоему это не большая проблема, и уж точно неповод для открытых конфликтов
Код в разных стилях в рамкох одного проекта просто мозолит глаза, и лично я всегда использую стиль проекта в котором учавствую. Но есть и более существуенные проблемы. Я, на самом деле, вообще не слежу за тем сколько пробелов я поставил и где — ИДЕЯ за меня все и так автоматически реформатит. Так вот, когда я начну пользоваться этим в чужом файле — она отреформатит весь файл, в результате маленькие изменения првевратятися в большие, что совершенно не удобно.
Лучше делать code review глазами, чем проверять на несущественные ворнинги роботами.
Это совсем не условность, а острая необходимость, если над проектом работает больше 1 человека и хоть кого-то заботит будущая поддержка продукта. Ваше отношение подходит только к работе в одиночестве. Тем более, что если уж лень тратить время на соблюдение стандарта, то на «периодическую чистку кода» его не будет совсем.
> Во-первых, если человек использует способ оформления кода отличный от вашего, то не стоит его называть говнокодером.
А какой стиль правильный? Вы никогда никому не докажете что ваш стиль лучше чьего-то. Для этого и есть стандарты и их следует соблюдать.
А какой стиль правильный? Вы никогда никому не докажете что ваш стиль лучше чьего-то. Для этого и есть стандарты и их следует соблюдать.
причем тут стиль оформления кода к говнокодерству?
Нельзя человека, который пишет натюрморты называть плохим художником, только по тому, что вы предпочитаете пейзажи.
Нельзя человека, который пишет натюрморты называть плохим художником, только по тому, что вы предпочитаете пейзажи.
Особенно весело, когда каждый разработчик генерирует 100500 изменений, потому что его стиль кодирования ему больше нравится. Т.е. вместо правки 1 строки трогает либо сам либо своим IDE весь файл, что конечно же не облегчит code review и будет загрязнять проект лишними данными
>Нельзя человека, который пишет натюрморты называть плохим художником, только по тому, что вы предпочитаете пейзажи.
Правильно, нельзя. Но я напрямую никого не обвиняю в своем посте. Просто это наболело и те кому приходилось столкнуться с этим наверняка поймут меня.
Правильно, нельзя. Но я напрямую никого не обвиняю в своем посте. Просто это наболело и те кому приходилось столкнуться с этим наверняка поймут меня.
> Просто это наболело и те кому приходилось столкнуться с этим наверняка поймут меня.
Из личного опыта могу сказать, что с годами приходит понимание и терпимость. И неправильный перенос строки уже не вызывает такого желания размозжить человеку голову.
Из личного опыта могу сказать, что с годами приходит понимание и терпимость. И неправильный перенос строки уже не вызывает такого желания размозжить человеку голову.
неправильный перенос — возможно. А вот множество однострочных конструкций, отсутствие коментариев ко всему что только можно, именование методов и классов, табы вперемешку с пробелами, 10-20 ретурнов в одном методе и тому подобные красоты, вызывает множество свойких желаний…
Так что CodeSniffer — это TRUE
Так что CodeSniffer — это TRUE
Для того чтобы наказать говнокодеров
Думаю говнокодеров не стоит брать на работу вообще…
А вот новичкам проекта полезно будет чтобы запомнить code-style проекта
Все замечательно, только хук надо вешать не на pre-commit, а на update в мастере.
не совсем понял? в локальном репозитории или удаленном? и почему именно в мастере?
Под мастером я подразумевал не ветку, а удаленный репозиторий в который отправляют свои комиты (куда делается git push).
У меня две проверки, при коммите на локальном и при добавлении на удаленный. На удаленном отправляется email старшему разработчику.
На локальном, ИМХО, хук вообще не нужен:
- можно проскипать при помощи --no-verify
- можно его вообще снести или временно отключить
- мешает быстренько закомитить локально (например, в конце рабочего дня, а завтра причесать)
- сложнее поддерживать, если пишете свои правила для проверки
так идея не в том чтобы отловить ошибки а чтобы их не было. Каждый за собой следит локально, а для нарушителей есть проверка удаленно.
>сложнее поддерживать, если пишете свои правила для проверки
Да в этом есть сложность. У нас в офисе на каждой машине есть папка смонтированная с сервера, для самых разных нужд. В ней же и лежат правила проверки. Таким образом все смотрят в одно место.
Вроде есть какая то возможность настроить PEAR чтобы он искал правила удаленно — это может понадобиться для распределенной команды. Но я пока с этим не разбирался.
>сложнее поддерживать, если пишете свои правила для проверки
Да в этом есть сложность. У нас в офисе на каждой машине есть папка смонтированная с сервера, для самых разных нужд. В ней же и лежат правила проверки. Таким образом все смотрят в одно место.
Вроде есть какая то возможность настроить PEAR чтобы он искал правила удаленно — это может понадобиться для распределенной команды. Но я пока с этим не разбирался.
1 и 3 пункты немного противоречат друг другу :)
А ещё можно этот шаг добавить в пайплайн Continuous Integration сервера
Да, интересная тема.
Что то видел об этом в PHPUnderControl. Есть примеры готовых связок сервера CI и скриптов проверки?
Что то видел об этом в PHPUnderControl. Есть примеры готовых связок сервера CI и скриптов проверки?
jenkins-php.org/ — я такой вот конфиг юзаю в качестве базового
btw, вот ещё интересный набор снифоф для юнит тестов: github.com/elblinkin/PHPUnit-CodeSniffer
руки пока не дошли, но вообще по статьям — вполне интересные
руки пока не дошли, но вообще по статьям — вполне интересные
На маджентовском проекте подобное хотели заимплементить, только в связке с гиториусом. Так как проект уже не новый (~25к комитов в истории). Идея была в том, чтобы запускать checkstyle только для того кода, который пушается, но потом сбились на проверку только тех файлов, которые затрагивает пуш. Когда были ошибки — не давали сделать пуш, но это как-то неправильно оказалось. Идея с письмом намного интереснее, спасибо вам.
>>Сравнительно недавно появился набор правил для проверки стандартов кодирования Drupal
пфф лучше б эти идиоты ядро нормальное запилили.
пфф лучше б эти идиоты ядро нормальное запилили.
Интересно, как быть если в проекте с одним стилем, понадобилось подключить библиотеку из проекта с другим стилем.
Например в Drupal сделан модуль с кусками Zend. Получается код модуля должен быть оформлен в одном стиле, Zend классы при этом оформлены в другом, все это идет скопом в коммит, на что естественно в ответ будут матюки от hook'ов.
Интересно если подключить сторонник классы как модуль, git вызовет для них эти hook'и и если не вызовет (то есть все ок и так и надо делать) то как быть если сторонник классы хостятся не на git, а к примеру на svn
Например в Drupal сделан модуль с кусками Zend. Получается код модуля должен быть оформлен в одном стиле, Zend классы при этом оформлены в другом, все это идет скопом в коммит, на что естественно в ответ будут матюки от hook'ов.
Интересно если подключить сторонник классы как модуль, git вызовет для них эти hook'и и если не вызовет (то есть все ок и так и надо делать) то как быть если сторонник классы хостятся не на git, а к примеру на svn
для этого, хук должен быть настроен так, что сторонние либы не проверялись. Так же как и устаревшие, архивные проекты например.
Для этого я хочу в следующем обновлении сделать конфиг, который возможно стоит добавлять в контроль версий, чтобы он был доступен для локального и удаленного скриптов проверки и был общим для каждого из разработчиков.
В этом конфиге, можно будет указывать файлы и папки которые не нужно проверять, например ядро Drupal, сторонние модули и features.
В этом конфиге, можно будет указывать файлы и папки которые не нужно проверять, например ядро Drupal, сторонние модули и features.
Хук вызовется при любом комите.
Надо PHP Code Sniffer скармливать только то, что нужно проверять, а не все, что есть в комите.
Насколько просто это сделать зависит от архитектуры.
Надо PHP Code Sniffer скармливать только то, что нужно проверять, а не все, что есть в комите.
Насколько просто это сделать зависит от архитектуры.
А лучше расположить на сервере и не post-receive, а pre-receive, чтобы вообще не давать коммитить нестандартный код.
Мы в наших проектах успешно используем подобный хук, но с настройками для игнора некоторых файлов и каталогов. Планирую его доработать, чтобы можно было настраивать уровень «фашизма» при проверке стандарта, т.к. иногда нужно быстро запушить код для фикса ошибки, а причесать его можно и потом.
Мы в наших проектах успешно используем подобный хук, но с настройками для игнора некоторых файлов и каталогов. Планирую его доработать, чтобы можно было настраивать уровень «фашизма» при проверке стандарта, т.к. иногда нужно быстро запушить код для фикса ошибки, а причесать его можно и потом.
Я выше об этом как раз и писал.
Так это замечательная вещь!!! Ведь соблюдения единого стиля кода на проекте очень важно! У меня раз человек на проекте 10 раз переписывал свой код, потому что мне по стилю не нравилось, но для этого мне приходилось проверять, что он коммитил. Так намного легче! Спасибо!
Или т.н. «стандарты кодирования» описаны их автором в виде настроек для IDE которой пользуется вся команда или это потеря времени, а т.н. «лиду» рановато пока быть «лидом».
Статья обновлена. Добавлена возможность исключить файлы и директории из проверки используя конфигурационный файл.
Ссылки в статье не кликабельные. Печаль.
Извиняюсь что так получилось, я добавил рабочую ссылку на скрипты. Надеюсь вам это будет полезно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проверка соблюдения стандартов кодирования РHP через git