В своей работе мы следуем стандартам кода php-fig и используем утилиту php-cs-fixer. Так как мы не любим рутинную работу, то мы автоматизировали применение данной утилиты с помощью скриптов, как например описано в статье Git и PHP Coding Standards Fixer, что позволяет нам всегда придерживаться стандартов кода вне зависимости от используемого редактора. Но при разработке в команде мы не можем быть уверены, что все настроили автоматические исправления на клиенте, поэтому встает проблема настройки дополнительной проверки на стороне сервера при pull request'ах. В данной статье я приведу пример такой настройки для проектов на Github.

Travis-ci

Travis в основном используется для тестирования, но мы будем его еще использовать и для проверки стиля кода.
Создаем в нашем репозитории файл .travis.yml с примерно таким содержимым:

language: php
php:
    - 5.5
    - 5.6
    - 7.0

before_script:
    - composer global require fabpot/php-cs-fixer
    - composer install --dev

script:
     - phpunit
     - php php-cs-fixer --diff --dry-run -v fix .

В данном случае нас интересуют следующие строки:

• composer global require fabpot/php-cs-fixer — позволяет установить fixer, который мы используем локально;
• php php-cs-fixer --diff --dry-run -v fix — позволяет нам проверить наш код на соответствие стандартам;

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

В случае ошибки travis-ci покажет нам где ошибка, например:

Если все прошло успешно, то будет сообщение вида:

The command "php-cs-fixer --diff --dry-run -v fix ." exited with 0.

В данном случае на сервере и на стороне разработчика мы используем одни и те же настройки стандартов кода. К примеру, можно дополнительно настроить файл .php_cs в репозитории, если по каким то причинам вам не подходят настройки по умолчанию.

Scrutinizer-ci

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

Чтобы настроить его для репозитория можно создать файл .scrutinizer.yml в корне библиотеки, примерно такого содержания:

checks:
    php:
        parameter_doc_comments: true
        return_doc_comments: true
        uppercase_constants: true
        use_self_instead_of_fqcn: true
        simplify_boolean_return: true
        remove_extra_empty_lines: true
        properties_in_camelcaps: true
        phpunit_assertions: true
        parameters_in_camelcaps: true
        optional_parameters_at_the_end: true
        no_short_variable_names:
            minimum: '3'
        no_short_method_names:
            minimum: '3'
        no_new_line_at_end_of_file: false
        no_goto: true
        newline_at_end_of_file: true
        line_length:
            max_length: '120'
        function_in_camel_caps: true
        encourage_single_quotes: true
        classes_in_camel_caps: true
        avoid_todo_comments: true
        avoid_perl_style_comments: true
        avoid_fixme_comments: true
        return_doc_comment_if_not_inferrable: true
        param_doc_comment_if_not_inferrable: true
        more_specific_types_in_doc_comments: true

filter: {  }
coding_style:
    php:
        braces:
            classes_functions:
                class: new-line
                function: new-line
        upper_lower_casing:
            keywords:
                general: lower
            constants:
                true_false_null: lower 

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

StyleCI

Для настройки данного сервиса необходимо подключить репозиторий. Если вам необходимы специальные настройки, создайте файл .styleci.yml с настройками. Например:

preset: symfony

risky: false

linting: true

enabled:
    - short_array_syntax

в данном примере мы используем предустановленные настройки symfony с дополнительными параметрами. Настроек очень много, подробная документация доступна на StyleCI. Но опять мы на сервере и локально используем разные настройки, что может привести к конфликтам.

Выводы

Было рассмотрено несколько сервисов, которые позволяют придерживаться единого стиля кода для сообщества разработчиков. Какой из них использовать решать вам, но стоит начать использовать уже сейчас, чтобы не было ситуации, когда разные файлы одного проекта написаны в разном стиле. Возможно, если вам будет интересно, в дальнейшем напишу статью о том как настроить контроль стиля кода для закрытых репозиториев на других хостингах (Gitlab,Bitbucket), поскольку методы данной статьи подходят для общедоступных проектов. Было бы интересно увидеть в комментариях какие средства для контроля стиля кода используете вы.