что такое psr php
PHP: Стандарты кодирования
Стандарт PSR-1. Основной стандарт кодирования
PSR-2. Стиль кодирования
Список аргументов функции МОЖНО разбить на несколько строк, каждая из которых с одним отступом. При этом первый аргумент в списке НЕОБХОДИМО перенести на следующую строку, и в каждой строке НЕОБХОДИМО указать только один аргумент.
12) while, do-while, for, foreach
Классы
1) Открывающие фигурные скобки классов НЕОБХОДИМО переносить на следующую строку, а закрывающие фигурные скобки переносить на следующую строку после тела.
2) Видимость НЕОБХОДИМО объявлять для всех свойств и методов (public, private. )
3) НЕОБХОДИМО оставлять одну пустую строку после объявления пространства имён (namespace) и НЕОБХОДИМО оставлять одну пустую строку после блока операторов use.
4) Ключевые слова extends и implements НЕОБХОДИМО располагать на одной строке с именем класса. Список implements МОЖНО разбить на несколько строк, каждая из которых с одним отступом. При этом первый интерфейс в списке НЕОБХОДИМО перенести на следующую строку, и в каждой строке НЕОБХОДИМО указать только один интерфейс.
5) НЕ СЛЕДУЕТ начинать название метода или свойства с подчёркивания для обозначения приватной или защищённой видимости.
6) НЕДОПУСТИМО в одном объявлении видимости указывать более одного свойства.
7) НЕДОПУСТИМО объявлять методы с пробелом после названия метода. Открывающую фигурную скобку НЕОБХОДИМО располагать на отдельной строке; закрывающую фигурную скобку НЕОБХОДИМО располагать на следующей строке после тела метода. НЕДОПУСТИМО оставлять пробел после открывающей круглой скобки и перед закрывающей.
В списке аргументов метода НЕДОПУСТИМЫ пробелы перед запятыми и НЕОБХОДИМ один пробел после каждой запятой.
8) Список аргументов МОЖНО разбить на несколько строк. Когда список аргументов разбит на несколько строк, закрывающую круглую скобку и открывающую фигурную НЕОБХОДИМО располагать на одной отдельной строке, с одним пробелом между ними.
9) При наличии ключевых слов abstract и final, НЕОБХОДИМО чтобы они предшествовали модификаторам видимости. При наличии ключевого слова static, НЕОБХОДИМО чтобы оно следовало за модификатором видимости.
10) Анонимные функции умышленно упущены в данной статье по той причине, что курс обходит их стороной. Но никто не мешает почитать.
PSR Стандарты
PSR — Чуть больше, чем стиль оформления кода.
Как показала практика, многие PHP-разработчики знакомы с аббревиатурой PSR. Однако большинство все еще ограничены знанием, что PSR это стандарт оформления кода.
Ребята из PHP-FIG (PHP Framework Interop Group), группа концепций совместимости PHP, которые занимаются развитием PSR (PHP Standards Recommendations) шагнули далеко вперед. Поэтому давайте разберемся, что из себя представляет PSR…
За последние полгода мне пришлось провести множество собеседований на позицию Middle PHP-Developer.
Один из вопросов, который я задавал всем кандидатам, был:- «Знаете ли Вы, что такое PSR?»
Как оказалось, практически всем кандидатам была знакома эта аббревиатура. Однако пытаясь рассказать подробнее, почти все разработчики указывали в основном на то, что это стандарт оформления кода (code style). Только некоторые упоминали про PSR-4 автозагрузку (использует Composer) и PSR-3 Logger Interface (в сети очень много однородных статей про PSR-0-1-2-3-4).
Мне кажется это весьма странным, так как термин PSR существует достаточно давно (уже более 10 лет) и каждый год набирает все большую популярность. Поэтому, думаю, будет неплохо собрать все в кучу и сделать обзор PSR стандартов.
PHP-FIG и PSR
PHP-FIG (PHP Framework Interop Group) — организованная в 2009 году группа разработчиков, основная идея которой находить способы совместной работы, выделяя общие концепции в разработке проектов на PHP.
Проще говоря, ребята стараются выделить что-то общее между различными проектами на разных фреймворках и сформировать некие стандарты (рекомендации) для дальнейшего периспользования.
Участники PHP-FIG
ReactPHP, Composer, Laminas Project (переименованный Zend Framework), Yii framework, CakePHP, Slim, Joomla, Magento, Drupal, phpBB, phpDocumentor и другие.
PSR (PHP Standards Recommendations) — описывает общие концепции, которые уже были проверены и отработаны. Вероятно при создании PSR, группа PHP-FIG вдохновлялась Java Community Process, а первый стандарт был принят в 2010 году.
Список PSR стандартов расширяется новыми, а сами стандарты делятся на категории:
Автозагрузка, Интерфейсы, HTTP и Стиль кодирования,
каждому из которых присваивается определенный статус:
Принят, Устаревший, Черновик и Заброшенный.
Далее мы рассмотрим принятые PSR стандарты по категориям:
Автозагрузка
Разработчики, которые «недолго» работают с PHP, вероятно не знакомы с проблемами импорта классов, ведь есть пространства имен, а сейчас вообще трудно представить проект без менеджера зависимостей Composer, которой решает все вопросы с автозагрузкой классов.
Однако так было не всегда, пространства имен появились только в PHP 5.3 (это был 2009 год), а первый релиз Composer состоялся в марте 2012 года. Но вот сам PHP существует гораздо дольше, как Personal Home Page с 1995 года и как Hypertext Preprocessor с 1998 года, однако только PHP 5 включает «полноценную объектную модель», релиз которого был в июле 2004 года. Бородатым разработчикам того времени приходилось как-то сражаться со всеми возникшими проблемами при импорте классов.
Не самый плохой пример импорта классов на PHP 14-ти летней давности:
(Напишите в комментариях, если узнали где использовался данный подход).
В дополнение, оставлю ссылку на статью, которая подробно описывает работу с пространством имен, решенные проблемы и PSR-4.
Интерфейсы
PHP развивается, набирает все большую популярность, а его инфраструктура пополняется огромным количеством различных инструментов.
Появляются проблемы с изучением и переиспользованием однотипного функционала, а менеджер зависимостей может затянуть целую кучу несвязанных однотипных зависимостей. (тут JavaScript разработчик улыбнется).
Поэтому принято решение стандартизировать некоторые общие концепции:
Если Ваш проект нуждается в расширенном функционале, МОЖНО расширять данный интерфейс, но СЛЕДУЕТ сохранять совместимость с описанными в данном стандарте правилами. Это позволит сторонним библиотекам, применяемых при разработке приложения, использовать централизованную систему логирования.
Это привело к ситуации, когда многие библиотеки реализуют свои собственные системы кэширования с различными уровнями функциональности. Эти различия заставляют разработчиков изучать несколько систем, которые могут предоставлять или не предоставлять необходимую им функциональность. Кроме того, разработчики кеширующих библиотек сами сталкиваются с выбором между поддержкой только ограниченного числа платформ или созданием большого количества классов адаптеров.
Чтобы решить эти проблемы был принят общий стандарт для библиотек реализующих кэширование, он включает в себя несколько интерфейсов:
Пользователи НЕ ДОЛЖНЫ передавать контейнер в объект, чтобы объект мог получить свои собственные зависимости. Это означает, что контейнер используется в качестве Service Locator, который обычно не рекомендуется использовать.
Отсюда, возникает простой вопрос: «Как это вообще работает»?
На самом деле все просто, на помощь приходит паттерн Factory, который возьмет на себя задачу создания объекта. А вот сам класс фабрики уже может принимать ContainerInterface и передавать в создаваемый объект необходимые зависимости.
Поэтому был принят PSR-16. Этот более простой подход направлен на создание стандартизированного оптимизированного интерфейса для общих случаев.
В списке реализаций все тот-же Symfony Cache и Laminas Cache (бывший Zend).
Если речь идет о WEB-приложении, то не важно на сколько сложная в нем бизнес-логика, по факту оно делает всего 2 вещи — принимает Request и отдает Response. Это значит, что так или иначе, приходится реализовывать эти объекты у себя в проекте.
Пожалуй, одной из самых сложных задач, которая нередко возникает является переиспользование кода между различными проектами. Если хорошо абстрагированные участки бизнес логики, некоторые компоненты и модули перенести возможно (с минимальными затратами), то с переносом более высокого уровня фреймворков (например контроллеров) возникают сложности.
Группа PHP-FIG пытается исправить данную проблему и предоставляет стандарты абстракции над HTTP.
А более детальное описание с примерами можно разобрать в статье «PSR-7 в примерах».
Если не вдаваться во все тонкости, то по сути это возможность писать некие абстрактные контроллеры для последующего переиспользования между различными проектами.
PSR-7 не содержит рекомендации о том, как создавать HTTP-объекты. Это может приводить к трудностям при необходимости их создания внутри компонентов, которые не привязаны к конкретной реализации PSR-7.
Интерфейсы, описанные в этой спецификации, описывают методы, с помощью которых можно создавать PSR-7 объекты.
Это может сделать библиотеки более пригодными для повторного использования, так как уменьшает количество зависимостей и снижает вероятность конфликтов версий.
Также в спецификации указано, что HTTP-клиенты могут быть заменены согласно принципу подстановки Лисков. Это означает, что все клиенты ДОЛЖНЫ вести себя одинаково при отправке запроса.
Пример реализации PSR-18 можно увидеть в библиотеке Symfony HTTP-client.
Предложенная абстракция над HTTP — это весьма серьезная заявка на попытку реализовывать действительно переиспользуемые и не зависящие от конкретных библиотек и фреймворков полноценные решения.
На практике, конечно все на много сложнее и есть свои нюансы и подводные камни, однако PHP-FIG делает значительный шаг вперед в этом направлении.
Стиль кодирования
До появления стандартов стиля кодирования, каждый из разработчиков оформлял свой код по-разному: одни писали CLASSNAME, другие ClassName, а третьи Class_Name, вечный спор относительно табов и пробелов, а еще StudlyCaps vs сamelCase vs snake_case и так далее.
Цель следующих PSR стандартов уменьшить когнитивное искажение при чтении кода от разных авторов.
PSR Стандарты
PSR — Чуть больше, чем стиль оформления кода.
Как показала практика, многие PHP-разработчики знакомы с аббревиатурой PSR. Однако большинство все еще ограничены знанием, что PSR это стандарт оформления кода.
Ребята из PHP-FIG (PHP Framework Interop Group), группа концепций совместимости PHP, которые занимаются развитием PSR (PHP Standards Recommendations) шагнули далеко вперед. Поэтому давайте разберемся, что из себя представляет PSR…
За последние полгода мне пришлось провести множество собеседований на позицию Middle PHP-Developer.
Один из вопросов, который я задавал всем кандидатам, был:- «Знаете ли Вы, что такое PSR?»
Как оказалось, практически всем кандидатам была знакома эта аббревиатура. Однако пытаясь рассказать подробнее, почти все разработчики указывали в основном на то, что это стандарт оформления кода (code style). Только некоторые упоминали про PSR-4 автозагрузку (использует Composer) и PSR-3 Logger Interface (в сети очень много однородных статей про PSR-0-1-2-3-4).
Мне кажется это весьма странным, так как термин PSR существует достаточно давно (уже более 10 лет) и каждый год набирает все большую популярность. Поэтому, думаю, будет неплохо собрать все в кучу и сделать обзор PSR стандартов.
PHP-FIG и PSR
PHP-FIG (PHP Framework Interop Group) — организованная в 2009 году группа разработчиков, основная идея которой находить способы совместной работы, выделяя общие концепции в разработке проектов на PHP.
Проще говоря, ребята стараются выделить что-то общее между различными проектами на разных фреймворках и сформировать некие стандарты (рекомендации) для дальнейшего периспользования.
Участники PHP-FIG
ReactPHP, Composer, Laminas Project (переименованный Zend Framework), Yii framework, CakePHP, Slim, Joomla, Magento, Drupal, phpBB, phpDocumentor и другие.
PSR (PHP Standards Recommendations) — описывает общие концепции, которые уже были проверены и отработаны. Вероятно при создании PSR, группа PHP-FIG вдохновлялась Java Community Process, а первый стандарт был принят в 2010 году.
Список PSR стандартов расширяется новыми, а сами стандарты делятся на категории:
Автозагрузка, Интерфейсы, HTTP и Стиль кодирования,
каждому из которых присваивается определенный статус:
Принят, Устаревший, Черновик и Заброшенный.
Далее мы рассмотрим принятые PSR стандарты по категориям:
Автозагрузка
Разработчики, которые «недолго» работают с PHP, вероятно не знакомы с проблемами импорта классов, ведь есть пространства имен, а сейчас вообще трудно представить проект без менеджера зависимостей Composer, которой решает все вопросы с автозагрузкой классов.
Однако так было не всегда, пространства имен появились только в PHP 5.3 (это был 2009 год), а первый релиз Composer состоялся в марте 2012 года. Но вот сам PHP существует гораздо дольше, как Personal Home Page с 1995 года и как Hypertext Preprocessor с 1998 года, однако только PHP 5 включает «полноценную объектную модель», релиз которого был в июле 2004 года. Бородатым разработчикам того времени приходилось как-то сражаться со всеми возникшими проблемами при импорте классов.
Не самый плохой пример импорта классов на PHP 14-ти летней давности:
(Напишите в комментариях, если узнали где использовался данный подход).
В дополнение, оставлю ссылку на статью, которая подробно описывает работу с пространством имен, решенные проблемы и PSR-4.
Интерфейсы
PHP развивается, набирает все большую популярность, а его инфраструктура пополняется огромным количеством различных инструментов.
Появляются проблемы с изучением и переиспользованием однотипного функционала, а менеджер зависимостей может затянуть целую кучу несвязанных однотипных зависимостей. (тут JavaScript разработчик улыбнется).
Поэтому принято решение стандартизировать некоторые общие концепции:
Если Ваш проект нуждается в расширенном функционале, МОЖНО расширять данный интерфейс, но СЛЕДУЕТ сохранять совместимость с описанными в данном стандарте правилами. Это позволит сторонним библиотекам, применяемых при разработке приложения, использовать централизованную систему логирования.
Это привело к ситуации, когда многие библиотеки реализуют свои собственные системы кэширования с различными уровнями функциональности. Эти различия заставляют разработчиков изучать несколько систем, которые могут предоставлять или не предоставлять необходимую им функциональность. Кроме того, разработчики кеширующих библиотек сами сталкиваются с выбором между поддержкой только ограниченного числа платформ или созданием большого количества классов адаптеров.
Чтобы решить эти проблемы был принят общий стандарт для библиотек реализующих кэширование, он включает в себя несколько интерфейсов:
Пользователи НЕ ДОЛЖНЫ передавать контейнер в объект, чтобы объект мог получить свои собственные зависимости. Это означает, что контейнер используется в качестве Service Locator, который обычно не рекомендуется использовать.
Отсюда, возникает простой вопрос: «Как это вообще работает»?
На самом деле все просто, на помощь приходит паттерн Factory, который возьмет на себя задачу создания объекта. А вот сам класс фабрики уже может принимать ContainerInterface и передавать в создаваемый объект необходимые зависимости.
Поэтому был принят PSR-16. Этот более простой подход направлен на создание стандартизированного оптимизированного интерфейса для общих случаев.
В списке реализаций все тот-же Symfony Cache и Laminas Cache (бывший Zend).
Если речь идет о WEB-приложении, то не важно на сколько сложная в нем бизнес-логика, по факту оно делает всего 2 вещи — принимает Request и отдает Response. Это значит, что так или иначе, приходится реализовывать эти объекты у себя в проекте.
Пожалуй, одной из самых сложных задач, которая нередко возникает является переиспользование кода между различными проектами. Если хорошо абстрагированные участки бизнес логики, некоторые компоненты и модули перенести возможно (с минимальными затратами), то с переносом более высокого уровня фреймворков (например контроллеров) возникают сложности.
Группа PHP-FIG пытается исправить данную проблему и предоставляет стандарты абстракции над HTTP.
А более детальное описание с примерами можно разобрать в статье «PSR-7 в примерах».
Если не вдаваться во все тонкости, то по сути это возможность писать некие абстрактные контроллеры для последующего переиспользования между различными проектами.
PSR-7 не содержит рекомендации о том, как создавать HTTP-объекты. Это может приводить к трудностям при необходимости их создания внутри компонентов, которые не привязаны к конкретной реализации PSR-7.
Интерфейсы, описанные в этой спецификации, описывают методы, с помощью которых можно создавать PSR-7 объекты.
Это может сделать библиотеки более пригодными для повторного использования, так как уменьшает количество зависимостей и снижает вероятность конфликтов версий.
Также в спецификации указано, что HTTP-клиенты могут быть заменены согласно принципу подстановки Лисков. Это означает, что все клиенты ДОЛЖНЫ вести себя одинаково при отправке запроса.
Пример реализации PSR-18 можно увидеть в библиотеке Symfony HTTP-client.
Предложенная абстракция над HTTP — это весьма серьезная заявка на попытку реализовывать действительно переиспользуемые и не зависящие от конкретных библиотек и фреймворков полноценные решения.
На практике, конечно все на много сложнее и есть свои нюансы и подводные камни, однако PHP-FIG делает значительный шаг вперед в этом направлении.
Стиль кодирования
До появления стандартов стиля кодирования, каждый из разработчиков оформлял свой код по-разному: одни писали CLASSNAME, другие ClassName, а третьи Class_Name, вечный спор относительно табов и пробелов, а еще StudlyCaps vs сamelCase vs snake_case и так далее.
Цель следующих PSR стандартов уменьшить когнитивное искажение при чтении кода от разных авторов.
Что такое PSR
PHP Standards Recommendations — это набор рекомендаций для разработчиков на PHP. Отношение к PSR разное: от полного неприятия, то фанатичной преданности. Сам по себе PSR появился как копирование Java Community Process (ага, опять Java!). Основное назначение PSR в том, чтобы предоставить PHP-разработчикам некие общие концепции, которые уже были проверены и отработаны.
На сегодняшний день существует 20 рекомендаций PSR. Часть из них находится в активном статусе, другие в виде черновиков. Есть «заброшенные» и отмененные рекомендации. В общем «движуха» достаточно активная. Попробуем во всём этом разобраться.
Стандарт или рекомендация?
В названии PHP Standards Recommendations неудачная игра слов — «стандарт» и «рекомендация» (стандартные рекомендации). Под стандартом обычно понимают то, чему следует строго и обязательно следовать. Рекомендация же, наоборот, лишь предлагает, но не обязывает. По своей сути PSR однозначно рекомендация, которая не требует исполнения.
Группа PHP Framework Interop Group предлагает рекомендации в качестве помощи PHP-разработчикам. То есть смысл в том, чтобы прийти к унификации при решении некоторых задач. Здесь есть некая тонкая грань, когда PSR начинает описывать не просто абстрактную теорию как нужно делать, а предлагает уже конкретный php-код, что во многих случаях может вызывать непонимание или даже неприятие. Но в любом случае PSR однозначно не отвечает за архитектуру приложения, а значит следовать рекомендациям или нет полностью ложится на решение разработчика.
Фундаментальные рекомендации, по сути стандарты
Самое важное, чего добилась группа PHP-FIG — это всё-таки заставила php-программистов следовать единому стилю написание кода. За это отвечают два стандарта:
На самом деле это лишь второстепенный фактор: качество кода никак не связано с его форматированием. Но, когда код предполагается для обозрения, то общепринятый формат упрощает его чтение. По факту же эти рекомендации больше всего востребованы в программах редакторах. Например я привык к стилю форматирования CodeIgniter. Но мне не сложно нажать автоформат в Visual Studio Code и получить полное соответствие PSR-1/12. Более того, если я встречаю чужую библиотеку, которая неряшливо оформлена, то опять же привести код в понятный — это один клик мышью.
ООП интерфейсы
Остальные рекомендации представляют собой обычные интерфейсы для создания своих классов. Читать такие PSR лучше с конца — исходного кода. Тогда будет понятно реальное назначение. По какой-то причине описание PSR начинается с многословного бла-бла-бла и многие разработчики воспринимают именно эту часть текста как безусловный «стандарт». Происходит подмена понятий, дескать, если не следовать этой рекомендации, то код становится устаревшим и плохим.
На самом же деле, каждая рекомендация направлена на решение определенной задачи. Если фреймворк или CMS решает её своим способом, то это не значит, что он плохой, а означает только то, что ему эта рекомендация просто не нужна.
PSR-3: Logger Interface
Назначение — ведение журнала протоколирования. То есть не просто лог в файл или на экран, а некая система, которая работает не только с текстом сообщения, но и его кодом важности. Этот код описан в документе RFC 5424:
То есть когда отправляется какое-то сообщение, то присваивается его код важности (это в самом простом понимании). Что предлагает PSR-3? Элементарную вещь — готовый интерфейс Psr\Log\LoggerInterface с методами:
Поскольку интерфейс это тип данных, то все наследники будут совместимы между собой. А это, в свою очередь, позволяет организовать такую структуру классов, чтобы использовать разные реализации логов. Например в одном приложении это будет запись в файл, в другом в базу данных, в третьем сразу на экран. Поскольку интерфейс один, то получается что можно использовать разные классы для реализации разных возможностей. В общем как это я рассказываю в ООП паттернах.
И здесь важный момент. Если в приложении нужен лог (а это очень частая задача), то не значит, что нужно обязательно делать его со всеми методами PSR-3. То есть всегда следует идти от реальной задачи и не создавать лишние связи/классы/файлы там, где этого не требуется.
PSR-6: Caching Interface
PSR-16: Common Interface for Caching Libraries
Интерфейс, который призван привести работу с разными видами кэширование к единым методам. То есть не важно как именно будет реализовано кэширование проекта, например через Memcached или обычные файлы, на «публику» следует отдать единые методы. PSR-6 предлагает их с избытком, видимо рассчитывая на особенности кэширующих библиотек.
PSR-7: HTTP message interfaces
PSR-11: Container interface
Описывает два метода для контейнера зависимостей. Это ООП-паттерн «Dependency injection» (я его ещё не публиковал). В DI предполагается, что есть некий контейнер, который хранит все зависимости. Скажем есть несколько классов, которые вначале добавляются/регистрируются в этом контейнере, а уже после «вытягиваются» из него по мере необходимости. PSR-11 предлагает, что получение это метод get() и has() для проверки существования зависимости.
Тут всё сильно завязано на внутреннюю архитектуру используемого фреймворка — если он сложный, то скорее всего использует свою реализацию, которой следует придерживаться. Для простых же вещей обычного ООП-подхода более чем достаточно.
PSR-13: Link definition interfaces
Смысл этой рекомендации в том, чтобы унифицировать методы работы с ссылками. Предлагается сразу несколько интерфейсов, методы которых должны возвращать разные атрибуты. Я не знаю где это вообще нужно, поскольку небольшой обёртки над стандартной parse_url() обычно хватает более чем.
PSR-14: Event Dispatcher
По сути это попытка создать ООП-паттерн Observer (Наблюдатель). Я его уже как-то описывал для Java. (Нужно будет, конечно, довыкладывать все остальные php-паттерны. ) Назначение PSR-14 в реализации событийной модели в приложении. Я никогда не сталкивался с подобной схемой, возможно это также завязка на какой-то фреймворк, но нюанс в том, что в PHP уже есть стандартные (без кавычек) интерфейсы для реализации полноценного паттерна Observer (SplSubject, SplObjectStorage и SplObserver).
PSR-15: HTTP Server Request Handlers
PSR-17: HTTP Factories
PSR-18: HTTP Client
Эти рекомендации развивают PSR-7. То есть опять же, если приложению как-то активно и своеобразно использует http-методы, то наверное есть смысл воспользоваться этими PSR.
Итоги
Нужны ли рекомендации PSR? На мой взгляд да, нужны. Самые главные стандарты — это стиль кодирования и автозагрузка — это то, что реально востребовано. Остальные рекомендации рассчитаны на специфичные задачи. Наверное правильней и честней было бы прямо указать, дескать это реализовано в таком-то фреймворке, давайте использовать аналогично. Поскольку этого нет, то и нет понимания того, где именно нужно использовать рекомендацию вне конкретного фреймворка.
Тут ещё следует отметить, что PHP-FIG формируют люди, которые имеют свои проекты. В каждом из них свои «велосипеды» и большинство несовместимы между собой. Каждый разработчик считает что его подход лучший, но это не значит, что все должны ему следовать. PHP очень гибкий язык, поэтому может быть множество реализаций одной задачи. Рекомендации PSR это взгляд с какой-то одной стороны и не всегда лучший. Скажем Symfony покинула группу PHP-FIG, а влияние Symfony очень велико: выкиньте из Laravel все Symfony-зависимости и что там останется? А если и все остальные сторонние модули. Так что в PHP-FIG всё не так гладко.
Хотя, возможно, настанет момент, когда крупные разработчики смогут предложить свою альтернативу, более конкретную и понятную, чем текущие рекомендации PSR. Ну а пока следовать им или нет, каждый решает сам. 🙂