 Вопрос к аудитории. Кто хочет поговорить про стандарты кода? Окей, я думал у нас будет, как всегда, лес рук в классе. К сожалению, не всегда все относятся с должным уважением к этому вопросу, и поэтому я предлагаю нам посмотреть одно замечательное видео. «Алимаж. Приколаж. Исусомом. Рулоцкорректор и нормальный». 37 секунд в лаунге. Управленные компьютеры решили 5.01 с 90 градусов. Итак, 10 лет и 7 миллиардов долларов потрачено на эту разработку. 4,5 тонны спутника и ракета-носители превратились в конфетти. В 1996 году авинус свалили на программистов. Пракотика не устает доказывать, что в любом ПО самое главное уязвимость – это человеческий фактор. И неважно, появился бах из-за нехватки квалификации у специалистов, или пережил долгие часы дебага и кюэ, и «Quality Assurance», или считался хитро замаскированной фичей. Среди некоторых разработчиков даже сложилось мнение, что баки в принципе есть всегда и везде. И в идеальной ситуации баки исправляются сразу, но должны исправляться сразу, но всегда у менеджмента есть очень много более других интересных задач, поэтому полный бакфиксинг и факторинг всегда откладывается и так далее. И вот эти вот отложенные баки, они являются такими некоторыми бомбами замедленного действия, но предотвратить некоторое количество этих бомб и бах можно следуя код-стандартам, паттернам, практикам написания кода и автоматизации проверки кода, той темы, которую немного затронул предыдущий спикер. Об этом и поговорим. Сразу скажу, что в том летательном аппарате не было людей, там были только спутники, поэтому, слава богу, никто не пострадал. Начнем с истории. Итак, познакомьтесь. Это стик Беккин. В ноябре 1999 года у него родилась дочь. Вместо того, чтобы отправиться в бар с друзьями, он решил написать немного кода. И у него это неплохо получилось. Настолько неплохо, что впоследствии этот код стал основой PIR. PIR — это первая библиотека класса в PHP, распространяемых через пакетный менеджер, почти как композер в наши дни. В нем были хорошие стандарты кода, и этот проект был настолько успешен, что в 2002 году вошел в состав в PHP. Коды летели, PHP успешно развивался, и начали появляться фреймворки. Их становилось все больше и больше, и у каждого из них были свои код-стандарты. И в какой-то момент было принято решение организоваться в специальную группу, которая будет путем открытого голосования создавать стандартные рекомендации к написанию кода на PHP. И так появился проект, который называется PHP FIG. В данный момент 37 разных библиотек, фреймворков и CMS входят в состав этой организацией, и они начали разрабатывать стандартные рекомендации. Это происходило примерно следующим образом. Голосуем за PSR-0, который регулирует стандарт автолодинга. Да, голосуем за PSR-1, который регулирует основные стандарты PHP. Да, голосуем за PSR-2, который регулирует стандарты написания кода. Да, ну и на 6-ом 7-ом PSR-е Symfony Reverse сказали No. И они дальше опять принимают какие-то новые стандарты, а Symfony LARVEL опять говорит No. И говорят, нам не нравится, как у вас тут все происходит, и поэтому мы уходим. А все говорят, оставайтесь на линии, ваш звонок очень важен для нас. И что ж, они нас покинули, очень жаль. И нашлепали еще 10 новых стандартов. Ну а что ж, наш любимый WordPress? Приходят и спрашивают, ребята, чем занимаемся? Они такие, о, мы принимаем рекомендации. Он так и говорит, я напишу свои. И написал для PHP, CSS, JavaScript, HTML, которые в принципе основаны на рекомендациях PIR. Конец истории. Возможно, все было не в точности так, как я рассказывал, но идею вы поняли. И дальше мы переходим, собственно, к теме вопроса. Пробежимся по конспекту. Кто не знает, кто забыл. И посмотрим, какие стандарты WordPress основные у нас есть. Начнем с PHP. Всегда используйте полные теги PHP, не используйте сокращенные. Используйте реальный символ табуляции для отступов, а не пробелы. Всегда ставьте пробелы. После запятой, с обеих сторонологических операторов, операторов присваивания. Ставьте пробелы с обеих сторон закрывающих и открывающих скобок. Между аргументами, в функциях. Когда выполняете логические операции, когда вызываете функции, ставьте пробелы. В названиях файлов и переменных используйте только символы нижнего регистра и подчеркивания для названий переменных, фильтров, функций. И никогда не используйте camel case PHP. В WordPress. У классов, правда, первые буквы заглавные в каждом слове. Если название класса аббревиатура, тогда все в верхнем регистре. Констакты все в верхнем регистре. А название файлов так же, как и переменные, все в нижнем, но через дефис. Если в файле класс, начинается файл обязательно класс и дефис и название самого класса. Важный момент читаемость кода, важнее его краткости и крутости. И используйте йода выражения, йода conditions. Идем дальше. HTML. Все теги должны быть закрыты. Даже если это не парный тег, у него должен быть обратный slash. Все теги и атрибуты в нижнем регистре. Все атрибуты должны иметь значение, и они должны быть в кавычках. При смешивании HTML и PHP соблюдайте логическую структуру. Опять же, используйте табы, не пробелы для отступов. Следующий момент CSS. Опять же, используйте табы, они пробелы. Каждый селектор должен быть с новой строки, закрывающая скобка на уровне с открывающей. И самые мои любимые в CSS стиле в селекторе должны быть в определенном порядке. Приблизительно можно их разбивать на такие логические группы. Или по алфавиту. Тоже допускается. И последняя JavaScript. Отступы табуляция. Используйте отступы там, где вам кажется это правильным и удобным для того, чтобы разделить логическую структуру и вообще код. Потому что все равно все будет форсировано в конечном счете, и это ни на что не повлияет. Скажите, уже пора сказать var в JavaScript до свидания. Уже используйте const и let. Переменный и название функции это полные слова, но в формате уже camel case. Длинные цепочки разбивайте на один вызов одна строка. Легкого, правда? Уверен, где-то там вдали есть человек, который такой сидит и думает, у него перестань, что я буду сейчас с линейкой бегать вот эти вот отступы вымерять. Когда уже там обед и следующий спикер. У меня для вас хорошие новости. Подождите, обед будет, следующий спикер тоже скоро. Но все это делать вручную не обязательно. И мы переходим к тому, что большую часть этой рутины и можно автоматизировать. Если вы используете git-композер, то после установки вот этих замечательных инструментов это все будет проверяться и проходится автоматически. И говорим к автоматизации. Какие у нас есть инструменты? Предыдущий докладчик затронул. Я буду использовать более простые базовые. У нас есть pshp.lint, который проверяет код на ошибки. На обычной ошибке. Где-то не закрытые теги, ковычки и так далее. Следующий инструмент pshp.cpd, который ищет в коде вашем в папке в теме дубликаты кода. И сообщает вам, что эти функции очень сильно похожи. Возможно, их стоит объединить. Это инструмент pshp.msdetector. Ищет возможные ошибки. Неоптимальный код. Сложные выражения. И неиспользуемые параметры, методы и свойства. И очень мощный инструмент. Это pshp.codesniffer со стандартами для WordPress. Он проверяет код на соответствии. Стандарта WordPress проверяет все эти отступы. Кроме того, там есть разные варианты, разные правила, которые могут проверять только основную. Следствие соответствия основным стандартам. Могут проверять, насколько документацию вы пишете хорошо. И также есть расширенные правила для проверки, когда кто-то использует функции устаревшие или запрещенные, например. Также есть возможность кодsnifferом проверять, насколько ваш код соответствует версии pshp, на котором вы собираетесь его запускать. Вы будете видеть, что этой функции в этой версии, например, нет. И очень полезные дополнения кодsnifferа это код beautifier и fixer. Который автоматически будет расставлять эти нудные пробелы там, где они нужны. Соответственно большая часть ошибок будет автоматизирована. Большая часть исправления будет автоматизирована. Все это легко установить. Буквально на каждые из этих инструментов одна команда в композере. У вас уже есть набор инструментов, который вам позволит писать код лучше. Саму проверку кода можно автоматизировать, используя, например, вот эти пакеты с гидхаба, которые что делают. Когда вы установили набор этих инструментов с помощью вот этих двух пакетов и есть остальные, вы можете подключиться на хук в гитте. И когда вы будете хук комита, когда вы будете комитить ваш код, вот эти два инструмента будут по очереди запускать все инструменты, которые я раньше сказал и они будут проверять ваш код. Если есть какие-то проблемы, то комит просто не произойдет. Вам вернется ошибка. Таким образом, это можно автоматизировать. Давайте посмотрим. Сейчас я покажу, когда работает у меня и потом на видео, а потом все объясню. Для примера возьмем горячо любимый, самый известный Apply Inward Press, какой. Hello Dolly, конечно же. Смотрим видео, и я потом все объясню. Здесь мы проверяем запускаются утилиты. И вот мы видим, что в этом плагине в соответствии с теми правила, которыми указали, 49 ошибок. И вот как-то происходит. Значит, сначала здесь я просто смотрю, какие файлы я буду добавлять. То есть, что будет комититься. Дальше запускается PHP lint, который проверяет, что нет ошибок. Их нет. Запускается Copy and Paste Detector тоже проверяет, что их нет. Потом запускается проверка на код стандартный и на правила. И находит 49 ошибок. И вот вы видите, есть полные описания этих ошибок в большинстве случаев. И есть вот такие вот ихсы, которые говорят о том, что Code Beautifier может автоматом исправить эту ошибку. И запускаю Code Beautifier и Fixer. 36 из этих ошибок фиксятся. То есть, это все, что связано с отступами и так далее. Таким образом, у нас остается в 13 ошибок, на которые стоит обратить внимание. Ну и вот в данном случае, например, используется функция MT-Rent вместо рекомендуемой WP-Rent и так далее. Не используется экранирование вывода и тому подобное. И давайте подведем итог. Пишите Code красиво используя стандарты. Пишите Code правильно. Используя проверенные готовые решения и паттерны. Пишите Code без ошибок. Используя средства для проверки качества кода. Титры. И сцена после титров. Что же, собственно, произошло с F22? Итак, 12 истребителей стоимостью 140 миллионов за штуку отправились с первым международный вылет в Акинаву, в Японию. И все шло замечательно, пока эскадрили они пересекла линию даты. Линию смены дат, даже смены дней. И после пересечения этой линии все 12 истребителей одновременно выдали сообщения об ошибке, потеряли и так далее, в конце концов удалось посадить. В чем же собственно было ошибка? Проектировщики забыли учесть вопрос пересечения линии дат и им просто не пришло в голову, что в какой-то момент нужно отнимать или прибавлять сутки. Собственно, у меня все. Спасибо за внимание. Желаю вам хорошего кода и спасибо, что дослушали до конца. Пишпишторм. А он вроде умеет это все делать? Да. Спасибо. Просто не все используют пишпишторм и поэтому была показана из терминала, когда все работает. Спасибо. Заклад Владимир. Расскажите нам интересный случай, какой ошибку вы допускали в своей карьере, и в которой можно было избежать с помощью этих инструментов. Спасибо, Максим. В принципе, скажу сразу, что желание описать качественный и красивый код у меня давно, поэтому все, что я пишу, оно по умолчанию проверяется, я, честно говоря, не вспомню такого случая, что сильно сломалось. Извини. Не обрадую тебя. Спасибо большое за доклад. Я использую WPCS, но есть проблема. Проблема заключается в том, что нет подобного линтера для HTML-кода, для JavaScript-кода и для CSS-кода. Скажите, пожалуйста, вы чем-то таким используете? Тут может быть аудитория мне поможет, но, по-моему, и нету, я вот кажется... Просто это устоявшиеся довольно инструменты, но пока для фронтенда нет ничего. Абсолютно. Да. По-моему, я что-то такое видел. Я лично не использую для PHP HTML и CSS. Для HTML и CSS JavaScript. Спасибо. Но мне кажется, я где-то видел такие инструменты. Давайте поищем их вместе. Есть они официальные для WordPress? Ну, окей. Не видел, пока еще не разработали по-настоящему. Видимо. Спасибо большое за доклад. У меня такой вопрос. Насколько часто меняются и обновляются именно стандарты WordPress и что делать с теми продуктами, которые уже были созданы? То есть надо подтягивать их и обновлять все под новые стандарты? Ну, это все спасибо за вопрос. Это все зависит, конечно, от возможностей клиента, бюджета и так далее. Я не знаю. То есть есть официальная страница, куда можно заходить и периодически просматривать. Но учитывая, что есть эти вещи для JavaScript с const и let, то все там достаточно актуально. И безусловно, там есть история, думаю, видно, где как что менялось. Что касается, я думаю, что периодически стоит уже написанные продукты пропускать через проверку, потому что, возможно, были найдены какие-то уязвимости и так вы их сможете обнаружить. Поэтому я обсоветовал периодически проверять.