PHP. Объекты, шаблоны и методики программирования

5 1 2 Часть IV. Практика

7 ERROR Private memЬer va riaЫe "users" must contain а l eading unde rscore
9 ERROR Opening brace should Ье оп а new l ine
1 3 ERROR Closing parenthesis o f а mul t i - l ine function call must Ье on а

l ine Ьу i t s e l f

На заметку. Один и з технических рецензентов этого издания книги, Вес Хант, сообщил о некоторых проблемах
с установкой CodeSniffer в системе Windows: "Поскольку Pear у меня был уже установлен, для успешной ин­
сталляции CodeSniffer мне пришлось почистить папку с : \Users \ { username ) \AppData \ Local \ Temp\
pear\cache".

Совершенно очевидно, для того чтобы зафиксировать мой код в хранилище
Zend, мне нужно соответствующим образом изменить свой стиль кодирования! Тем
не менее при работе в команде имеет смысл определить правила оформления кода.
По сути, решение. какой набор правил выбрать, вероятно. менее важное. чем ре­
шение. каких общих стандартов придерживаться сначала. Если сохранена целост­
ность кодовой базы. то сам код легко читать и с ним легко работать. Например. при­
нятое соглашение по присвоению имен поможет вам сразу же выяснить назначение
переменной или свойства.

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

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

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

Как и следовало ожидать. сейчас я добавлю задачу codesni f f e r в свой файл по­
строения.

< target name= "sni f f " depends="build">
<mkdir dir=" $ ( bu i ld ) / reports" />
<phpcodesniffer standard= " Zend">
<fileset dir="$ { build} /userthing">
< i nclude name= " * * / * . php" / >
</fileset>
< formatter type="checks tyle" out fi le=" $ ( bu i ld ) / repo rts /checkstyle . xml " / >
<formatter type="defau l t " usefi l e= " fa l s e " / >
< /phpcodesniffer>

< / target>

Задача phpcodes n i f f e r сделает всю описанную выше работу вместо меня. В ней
я воспользовался атрибутом s t a nda rd, чтобы указать набор правил Zend. Набор фай­
лов для проверки определен с помощью вложенного элемента f i leset. Здесь я опре­
делил два элемента f o rma t t e r . В первом из них для атрибута t ype выбрано значение
che c k s t y l e , а файлы отчета в формате ХМL будут записываться в каталог repo r t s .
В о втором элементе f o rma t t e r дл я атрибута t ype выбрано значение de fau l t . а свод­
ная информация об отчете выводится в командную строку.