стандарты оформления кода php
Стандарты кодирования PHP (PSR)
Группа взаимодействия фреймворков (PHP-FIG) окончательно приняла рекомендации к стандартам оформления кода на PHP.
Оригинальные тексты можно посмотреть на гитхабе.
PSR-0: требования к названиям классов
и неймспейсов для универсального автозагрузчика.
Полное имя класса должно быть вида `\ \( \)* `
PSR-1: Основные стандарты кодирования
Секция описывает общие правила оформления кода:
— Использование только тэгов
namespace Vendor\Package ;
use FooInterface ;
use BarClass as Bar ;
use OtherVendor\OtherPackage\BazClass ;
final public static function bar ( )
<
// method body
>
>
В голосовании по принятию стандартов участвовали разработчики таких проектов, как
Agavi
CakePHP, CakePHP 2
Chisimba, C4
Composer, Packagist
Doctrine, Doctrine2, et al.
Drupal
eZ Publish
FLOW3
Joomla
Lithium
PEAR, PEAR2
phpBB
PPI, PPI2
Propel, Propel 2
SabreDAV
Solar Framework, Aura Project
Symfony, Symfony2
Zend Framework, Zend Framework 2
Zikula
Соответствование требованием конкретных проектов можно посмотреть на
гугл докс
Но, сдавать код в общий проект будьте добры по тем правилам, которые установлены для всех (или в организации, где вы работаете). Стандарт на то и стандарт, чтобы любой разработчик мог открыть код и начать с ним работать, а не тратить время на его форматирование под себя.
PSR-2. Руководство по оформлению кода
Это руководство продолжает и расширяет PSR-1, основной стандарт написания кода.
Целью данного руководства является снижение когнитивных трений при беглом осмотре кода от разных авторов. Оно делает это путем перечисления общих наборов правил и ожиданий о том, как оформлять PHP код.
Эти правила оформления являются производным от сходства между разными участвующими проектами. Когда разные авторы сотрудничают в нескольких проектах, это помогает иметь один набор нормативов для использования между всеми этими проектами. Таким образом польза этого руководства не в самих правилах, а в обмене этими правилами.
Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «БУДЕТ», «НЕ БУДЕТ», «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ», и «ДОПОЛНИТЕЛЬНО» в этом документе должны быть истолкованы как описано в RFC 2119.
1. Обзор
Код ДОЛЖЕН следовать PSR-1.
Код ДОЛЖЕН использовать 4 пробела для отступов, не табуляцию.
НЕ ДОЛЖНО быть жесткого ограничения на длину строки; мягкое ограничение ДОЛЖНО быть 120 знаков; строкам СЛЕДУЕТ быть 80 символов или менее.
Открывающие фигурные скобки для классов ДОЛЖНЫ быть на новой строке, и закрывающие фигурные скобки ДОЛЖНЫ быть на новой строке после тела класса.
Открывающие фигурные скобки для методов ДОЛЖНЫ быть на новой строке, и закрывающие фигурные скобки ДОЛЖНЫ быть на новой строке после тела метода.
Область видимости ДОЛЖНА быть описана у всех свойств и методов; abstract и final ДОЛЖНЫ быть описаны перед областью видимости; static ДОЛЖНО быть описано после области видимости.
Ключевые слова управляющих конструкций ДОЛЖНЫ иметь один пробел после себя; вызовы методов и функции НЕ ДОЛЖНЫ.
Открывающие фигурные скобки для управляющих конструкций ДОЛЖНЫ быть на той же строке, а закрывающие фигурные скобки ДОЛЖНЫ быть на новой строке после тела конструкции.
Открывающие круглые скобки для управляющих конструкций НЕ ДОЛЖНЫ иметь пробел после себя, а закрывающие круглые скобки для управляющих конструкций НЕ ДОЛЖНЫ иметь пробел перед собой.
1.1. Пример
Этот пример как краткий обзор включает в себя некоторые из ниже указанных правил:
2. Общее
2.1 Основной стандарт написания кода
Код ДОЛЖЕН следовать всем правилам изложенным в PSR-1.
2.2 Файлы
Все PHP файлы ДОЛЖНЫ использовать переводы строк Unix LF (linefeed).
Все PHP файлы ДОЛЖНЫ оканчиваться одной пустой строкой.
2.3. Строки
НЕ ДОЛЖНО быть жесткого ограничения на длину строки.
Мягкое ограничение на длину строки ДОЛЖНО быть 120 знаков; автоматические проверки стиля ДОЛЖНЫ предупредить но НЕ ДОЛЖНЫ выдавать ошибку на мягкие ограничения.
Строкам НЕ СЛЕДУЕТ быть длиннее 80 знаков; более длинные строки СЛЕДУЕТ разбивать на несколько последующих строк не более чем 80 знаков в каждой.
НЕ ДОЛЖНО быть замыкающий пробелов в конце строки на не пустых строках.
Пустые строки МОГУТ быть добавлены для улучшения читабельности и указания связанных блоков кода.
НЕ ДОЛЖНО быть более одного оператора в строке.
2.4. Отступы
Код ДОЛЖЕН использовать отступ в 4 пробела, и НЕ ДОЛЖЕН использовать табуляцию для отступов.
Обратите особое внимание: Использование только пробелов, и не смешивание пробелов и табуляции, помогает избежать проблем с диффами, патчами, историей, и аннотациями. Использование пробелов также позволяет легко вставить тонко-настроенный суб-отступ для межстрочного выравнивания.
2.5. Ключевые слова и True/False/Null
PHP Ключевые слова ДОЛЖНЫ быть в нижнем регистре.
3. Объявление Пространства имен и Use
ДОЛЖНО быть ключевое слово use на каждое объявление.
4. Классы, Свойства, и Методы
Термин «класс» относится ко всем классам, интерфейсам и трейтам.
4.1. Extends и Implements
Ключевые слова extends и implements ДОЛЖНЫ быть объявлены на той же строке, что и имя класса.
Открывающая фигурная скобка для класса ДОЛЖНА идти на своей собственной строке; закрывающая фигурная скобка для класса ДОЛЖНА идти на следующей строке после тела класса.
Список implements МОЖЕТ быть разделен на несколько строк, где каждая последующая строка с одним отступом. При этом первый элемент в списке ДОЛЖЕН быть на следующей строке, и ДОЛЖЕН быть только один интерфейс на строку.
4.2. Свойства
Область видимости ДОЛЖНА быть объявлена на все свойства.
Ключевое слово var НЕ ДОЛЖНО быть использовано для объявления свойства.
НЕ ДОЛЖНО быть более одного свойства объявленного на оператор.
Имена свойств НЕ СЛЕДУЕТ делать с подчеркиванием в качестве приставки для обозначения области видимости protected или private.
Объявление свойства выглядит следующим образом.
4.3. Методы
Область видимости ДОЛЖНА быть объявлена на все методы.
Имена методов НЕ СЛЕДУЕТ делать с подчеркиванием в качестве приставки для обозначения области видимости protected или private.
Имена методов НЕ ДОЛЖНЫ быть объявлены с пробелом после имени метода. Открывающая фигурная скобка ДОЛЖНА идти на своей собственной строке, а закрывающая фигурная скобка ДОЛЖНА быть на следующей строке после тела метода. НЕ ДОЛЖНО быть пробела после открытия круглой скобки, и НЕ ДОЛЖНО быть пробела перед закрывающей круглой скобкой.
Объявление метода выглядит следующим образом. Обратите внимание на размещение круглых скобок, запятых, пробелов и фигурных скобок:
4.4. Аргументы Метода
В списке аргументов, НЕ ДОЛЖНО быть пробела перед каждой запятой, и ДОЛЖЕН быть один пробел после каждой запятой.
Аргументы Метода со значениями по умолчанию должны идти в конце списка аргументов.
Список аргументов МОЖЕТ быть разделен на несколько строк, где каждая последующая строка с одним отступом. При этом первый элемент в списке ДОЛЖЕН быть на следующей строке, и ДОЛЖЕН быть только один аргумент на строку.
Когда список аргументов разделен на несколько строк, закрывающая круглая скобка и открывающая фигурная скобка ДОЛЖНЫ быть установлены вместе на их собственную строку с одним пробелом между ними.
Если они присутствуют, то abstract и final ДОЛЖНЫ предшествовать перед объявлением области видимости.
4.6. Вызовы Метода и Функции
При выполнении вызова метода или функции, НЕ ДОЛЖНО быть пробела между именем метода или функции и открывающей круглой скобкой, НЕ ДОЛЖНО быть пробела после открытия круглой скобки, а также НЕ ДОЛЖНО быть пробела перед закрывающей круглой скобкой. В списке аргументов, НЕ ДОЛЖНО быть пробела перед каждой запятой, и ДОЛЖЕН быть один пробел после каждой запятой.
Списки аргументов МОГУТ быть разделены на несколько строк, где каждая последующая строка с одним отступом. При этом первый элемент в списке ДОЛЖЕН быть на следующей строке, и ДОЛЖЕН быть только один аргумент на строку.
5. Управляющие конструкции
Общие правила стиля для управляющих конструкций следующие:
Тело каждой конструкции ДОЛЖНО быть заключено в фигурные скобки. Это стандартизирует вид конструкций, и уменьшает вероятность внесения ошибок при добавлении новых строк к телу управляющей конструкции.
Оператор if выглядит следующим образом. Обратите внимание на размещение круглых скобок, пробелов и фигурных скобок; и что else и elseif находятся на одной линии, как и закрывающая фигурная скобка тела оператора.
Ключевое слово elseif СЛЕДУЕТ использовать вместо else if так что все управляющие ключевые слова выглядят как единые слова.
Оператор while выглядит следующим образом. Обратите внимание на размещение круглых скобок, пробелов и фигурных скобок.
Кроме того, оператор do while выглядит следующим образом. Обратите внимание на размещение круглых скобок, пробелов и фигурных скобок.
5.4. for
Оператор for выглядит следующим образом. Обратите внимание на размещение круглых скобок, пробелов и фигурных скобок.
5.5. foreach
Оператор foreach выглядит следующим образом. Обратите внимание на размещение круглых скобок, пробелов и фигурных скобок.
Блок try catch выглядит следующим образом. Обратите внимание на размещение круглых скобок, пробелов и фигурных скобок.
6. Замыкания
Открывающая фигурная скобка ДОЛЖНА идти на той же строке, а закрывающая фигурная скобка ДОЛЖНА идти на следующей строке после тела функции.
НЕ ДОЛЖНО быть пробела после открывающей круглой скобки списка аргументов или списка переменных, и НЕ ДОЛЖНО быть пробела перед закрывающей круглой скобкой списка аргументов или списка переменных.
В списке аргументов и списке переменных НЕ ДОЛЖНО быть пробела перед каждой запятой, и ДОЛЖЕН быть один пробел после каждой запятой.
Аргументы замыкания со значениями по умолчанию должны идти в конце списка аргументов.
Объявление замыкания выглядит следующим образом. Обратите внимание на размещение круглых скобок, запятых, пробелов и фигурных скобок:
Список аргументов и список переменных МОЖЕТ быть разделен на несколько строк, где каждая последующая строка с одним отступом. При этом первый элемент в списке ДОЛЖЕН быть на следующей строке, и ДОЛЖЕН быть только один аргумент или переменная на строку.
Когда конечный список (или аргументов или переменных) разделен на несколько строк, закрывающая круглая скобка и открывающая фигурная скобка ДОЛЖНЫ быть установлены вместе на их собственную строку с одним пробелом между ними.
Ниже приведены примеры замыканий с и без списка аргументов и списка переменных разбитого на несколько строк.
Обратите внимание, что правила форматирования применяются также когда замыкание используется прямо как аргумент при вызове метода или функции.
7. Заключение
Есть много элементов оформления и практик умышленно опущенных в этом руководстве. Они включают, но не ограничиваются:
Объявление глобальных переменных и глобальных констант
Операторы и присваивания
Комментарии и блоки документации
Приставки и окончания имен классов
Будущее рекомендации МОГУТ пересмотреть и расширить это руководство для решения тех или иных элементов оформления и практик.
PHP Code Style Conventions
В данной статье рассматривается подход к написанию и оформлению PHP кода. Нижеизложенные моменты были сформированы путем анализа существующих подходов компаний и личного опыта.
Правила именования файлов и папок
Все названия для папок и файлов должны быть осмысленными и говорящими (не требующие дополнительного разъяснения).
Папки
Если папка хранит в себе классы, которые относятся к пространству имен (namespace), то папка именуется в соответствии с названием пространства имен (namespace).
Файлы
Если файл является файлом класса, то именуется в соответствии с названием класса.
Правила именования пространств имен, классов, методов и переменных
Все названия должны быть осмысленными и говорящими (не требующие дополнительного разъяснения).
Пространства имен
Названия пространств имен должны быть в нижнем регистре и состоять из одного слова. В случае необходимости именовать пространств имен более одного слова производится дробление на составные части, являющиеся вложенными пространствами имен.
Классы
Методы
К названиям методов применяются следующие правила:
Переменные
К названиям переменных применяются следующие правила:
Название переменной должно передавать намерения программиста
Название переменной должно сообщить, почему эта переменная существует, что она делает и как используется
Название переменной не должно быть коротким
Если переменная хранит признак, то он должен быть включен в название ( unpaidProject )
Переменные и свойства объекта должны являться существительными и называться так, чтобы они правильно читались при использовании, а не при инициализации
Плохо:
Хорошо:
Запрещены отрицательные логические названия
Плохо:
Хорошо:
Правила оформления кода
В первую очередь ставится пространство имен (namespace), которое используется (если есть). Далее пишется конструкции использования классов ( use ). В случае использования нескольких
классов одного пространства имен происходит группировка с помощью конструкции <. >. Далее идет объявление класса.
Фигурные скобки ставятся на той же строке и разделяются пробелом.
Каждая переменная должна быть объявлена на новой строке.
Условия и служебные вызовы методов разделяются переносом строки, переменные и работа с ними переносами строк не разделяются.
Внутри условий и циклов дополнительный перенос на новую строку не ставится.
Содержимое класса разделяется сверху одной пустой строкой.
Перед возвращаемым значением( return ) обязательно ставится перенос строки, если метод не состоит из единственной строки.
Если условие является большим, то обязательно выделить его в одно или несколько смысловых выражений и использовать его (их) в условии.
Плохо:
Хорошо:
Комментирование кода
В общем случае комментарии запрещены (НЕ «всегда»). Любой участок кода, который необходимо выделить или прокомментировать, надо выносить в отдельный метод.
Комментарии должны быть расположены перед объявлением классов, переменных и методов и быть оформлены в соответствии с PHPDoc. Комментарий перед классом должен содержать описание бизнес-логики и отражать его назначение с приведением примеров использования.
Готовые алгоритмы, взятые из внешнего источника, должны быть помечены ссылкой на источник.
Правила написания кода
Везде, где имеет смысл, должнно быть прописано declare(strict_types=1);
Нельзя изменять переменные, которые передаются в метод на вход (исключение — если эта переменная объект).
Строки обрамляются одинарными кавычками. Двойные кавычки используются только, если:
Вместо лишней конкатенации используем подстановку переменных в двойных кавычках
Метод должен явно отличать нормальные ситуации от исключительных.
По умолчанию тексты исключений не должны показываться пользователю. Они предназначены для логирования и отладки. Текст исключения можно показать пользователю, если оно явно для этого предназначено.
В условном операторе должно проверяться исключительно boolean значение. В сравнении не boolean переменных используется строгое сравнение с приведением типа ( === ), автоматическое приведение и нестрогое сравнение не используются.
При использовании в условном выражении одновременно операторов И и ИЛИ обязательно выделять приоритет скобками.
Стандарты оформления кода php
Цель данных рекомендаций — снижение сложности восприятия, поддержки, тестирования и расширения кода, написанного разными авторами; она достигается путём рассмотрения серии правил и ожиданий относительно написания PHP-кода.
Слова «НЕОБХОДИМО» / «ДОЛЖНО» («MUST»), «НЕДОПУСТИМО» («MUST NOT»), «ТРЕБУЕТСЯ» («REQUIRED»), «НУЖНО» («SHALL»), «НЕ ПОЗВОЛЯЕТСЯ» («SHALL NOT»), «СЛЕДУЕТ» («SHOULD»), «НЕ СЛЕДУЕТ» («SHOULD NOT»), «РЕКОМЕНДУЕТСЯ» («RECOMMENDED»), «МОЖЕТ» / «ВОЗМОЖНО» («MAY») и «НЕОБЯЗАТЕЛЬНО» («OPTIONAL») в этом документе следует понимать так, как это описано в RFC 2119 (и его переводе).
1.1. Базовый стандарт оформления кода
Код ДОЛЖЕН быть оформлен согласно всем правилам, указанным в стандарте PSR-12.
Жесткое ограничение строки ДОЛЖНО составлять 120 символов. В случае превышения этого ограничения автоматические системы проверки стиля ДОЛЖНЫ считать это ошибочной ситуацией, для таких ситуаций НЕОБХОДИМО явно отключать проверку стиля с помощью аннотаций:
1.3. Выравнивание присвоений переменных и элементов массива
Блок присвоений ДОЛЖЕН быть выровнен по самому длинному присвоению в блоке. Если операция присвоения превышает максимальную длину строки НЕОБХОДИМО:
При объявлении многострочного массива в конце последнего объявления ДОЛЖНА ставиться запятая, для однострочного массива запятую ставить НЕДОПУСТИМО.
1.5. Последовательность вызовов (Chaining)
Каждый элемент вызова для последовательностей, состоящих из трех и более элементов ДОЛЖЕН находиться на новой строке. В случае превышения максимальной длины строки каждый элемент последовательности вызовов ДОЛЖЕН находиться на новой строке.
1.6. Выделение управляющих инструкций
2.1. Базовый стандарт для оформления документации в коде
Код ДОЛЖЕН быть оформлен согласно правилам, указанным в стандарте PSR-19.
2.2. Дублирование типов в docblock
2.3. Массивы в docblock
Типы элементов массивов РЕКОМЕНДУЕТСЯ уточнять в docblock.
2.4. Неопределенные типы аргументов и возвращаемых результатов
В случае, если аргумент (или возвращаемый результат) метода может быть разных типов НЕОБХОДИМО перечислить все допустимые типы в docblock.
Если ожидаемый тип переменной явно не определен НЕОБХОДИМО определить его с помощью однострочного docblock комментария. Так же необходимо указывать ожидаемый тип, если IDE не может его определить, или определяет не корректно.
Свойства класса ДОЛЖНЫ содержать либо декларацию типа, либо docblock для всех возможных типов значений, которое они могут содержать. ДОПУСТИМО указывать декларацию типа и docblock только в случаях, когда dockblock уточняет декларацию, либо при наличии комментария. Если docblock МОЖЕТ быть описан одной строкой — ДОЛЖЕН использоваться однострочный docblock.
2.7. Методы и функции
Docblock для методов и функций ДОЛЖНЫ быть многострочными.
3. Объявление констант, свойств и методов
3.1. Последовательность объявлений констант, свойств и методов
В классе ДОЛЖНА соблюдаться последовательность объявлений элементов согласно следующему списку:
3.2. Именование свойств
Названия свойств ДОЛЖНЫ описывать предназначение данных, которые они хранят.
3.3. Разделение свойств
Каждое свойство ДОЛЖНО отделяться от других свойств, констант и методов одной пустой строкой. Если свойство объявляется, как первый элемент класса — пустая строка перед ним НЕДОПУСТИМА. Если свойство объявляется, как последний элемент класса — пустая строка после него НЕДОПУСТИМА.
3.4. Модификаторы доступа для свойств
Для модификаторов доступа к свойствам ДОЛЖНЫ выполняться следующие правила:
Свойства класса ДОЛЖНЫ содержать либо декларацию типа, либо docblock для всех возможных типов значений, которое они могут содержать.
3.6. Именование методов
Названия методов ДОЛЖНЫ описывать предназначение их использования внешним кодом, а не детали реализации.
3.7. Разделение методов
Каждый метод ДОЛЖЕН отделяться от других методов, свойств и констант одной пустой строкой. Если метод объявляется, как первый элемент класса — пустая строка перед ним НЕДОПУСТИМА. Если метод объявляется, как последний элемент класса — пустая строка после него НЕДОПУСТИМА.
3.8. Модификаторы доступа для методов
Для модификаторов доступа к свойствам ДОЛЖНЫ выполняться следующие правила:
3.9. Порядок аргументов в методе
Аргументы метода ДОЛЖНЫ объявляться в следующей последовательности:
3.10. Массив в виде аргумента
4.1. Неявные приведения типов
Неявное приведение типов НЕДОПУСТИМО.
Неявное приведение типов — один из наиболее распространенных источников ошибок. Проблемы, возникающие при неявном приведении типов сложно отслеживать, так же они могут приводить к непредсказуемым последствиям.
4.2. Сравнения с преобразованием типов
Проблемы тут те же, что и при неявном приведении типов.
4.3. Инструкция switch
Использовать инструкцию switch НЕОБХОДИМО с гарантией корректности типов каждого проверяемого выражения.
Инструкция switch при выполнении проверок case использует сравнения с приведением типов. Это может привести к тем же проблемам, что и неявное приведение типов.
4.4. Присвоения в условных операциях
Создание ошибок с помощью trigger_error НЕДОПУСТИМО, вместо этого ДОЛЖНЫ использоваться исключения.
4.6. Оператор управления ошибками @
Оператор @ ДОЛЖЕН быть использован для выражений, которые могут бросить ошибку, для остальных ситуаций его использование НЕДОПУСТИМО. В случае подавления ошибки ДОЛЖНО быть брошено исключение с описанием причин возникновения ошибки.
Использование инструкции goto НЕДОПУСТИМО.
Оператор goto используется для перехода в другую часть программы, чем усложняет чтение и понимание кода.
Использование инструкции eval НЕДОПУСТИМО.
4.9. Глобальные переменные и global
Использование инструкции global НЕДОПУСТИМО.
Глобальные переменные являются неявными аргументами функции, или метода, не гарантирующими ни тип, ни значение, ни даже своего существования.
4.10. Статические свойства
Использование статических свойств НЕДОПУСТИМО.
Статические свойства, по аналогии с глобальными переменным являются неявными аргументами функции, или метода, не гарантирующими ни тип, ни корректного состояния.
4.11. Суперглобальные переменные
Использование суперглобальных переменных ДОЛЖНО быть сведено к минимуму. Данные из суперглобальных переменных РЕКОМЕНДУЕТСЯ получать на этапе инициализации.
4.12. Динамическая подстановка имен
Динамическая подстановка имен переменных, свойств, функций и методов НЕДОПУСТИМА.
Динамическая подстановка имен сильно усложняет чтение и отладку кода потому, что конечные имена определяются только в рантайме.
4.13. Магические методы
Использование следующих магических методов НЕДОПУСТИМО:
Данные методы усложняют чтение и понимание кода, как следствие его поддержку.
4.14. Валидация аргументов
Каждый аргумент публичного метода, защищенного метода, или функции ДОЛЖЕН быть проверен на корректность типа и граничные значения. Каждый аргумент приватного метода ДОЛЖЕН быть проверен на корректность типа, проверять граничные значения РЕКОМЕНДУЕТСЯ. Если аргумент не валиден — штатное выполнение метода (функции) невозможно, по этой причине ДОЛЖНО быть брошено исключение.
4.16. Обработка часовых поясов
В случае хранения или обработки времени со смещением по часовому поясу есть большая вероятность возникновения ошибок связанных с несоответствием часовых поясов.
Для подстановки параметров в SQL запросы НЕОБХОДИМО использовать псевдопеременные.
Подстановка параметров с помощью конкатенации ведет к целому классу проблем безопасности: sql-инъекции.
5. Принципы программирования
Принцип Здравого Смысла разрешает отмену любого правила данных рекомендаций, в случае, когда правило приводит к чрезмерному усложнению поддержки кода. Этот принцип МОЖНО использовать, но очень осторожно.
РЕКОМЕНДУЕТСЯ следовать принципу YAGNI.
Код ДОЛЖЕН следовать принципам SOLID.
Принципу DRY СЛЕДУЕТ придерживаться только в случае, когда он не противоречит SOLID и Здравому смыслу.
Примеры, когда не стоит следовать принципу DRY:
У вас есть две разных сущности, отвечающие разным доменам с некой общей функциональностью. В такой ситуации не стоит наследовать сущности одну от другой, или общую функциональность выносить в абстрактный класс, или трейт. Дело в том, что общая функциональность является общей только в текущий момент времени, в будущем же она может измениться в каждом домене по своему. Фактически вам придется в общей функциональности реализовывать ее разделение, в зависимости от домена.
В тестах DRY может привести к ложно позитивным и ложно негативным ошибкам.
Принципу KISS СЛЕДУЕТ придерживаться только в случае, когда он не противоречит другим правилам данных рекомендаций.
Примеры, когда не стоит следовать принципу KISS:
Методы должны быть «не большого размера». Здесь проблемы те же, что и у классов. Разделяя метод на множество маленьких вы расширяете интерфейс класса, что в будущем может привести к излишней связанности, как с данным классом, так и с его наследниками.
Принцип TMTOWTDI НЕ РЕКОМЕНДУЕТСЯ использовать.
Множество способов реализации одного и того же алгоритма ведет к тому, что правки алгоритма придется выполнять в каждой реализации, что в свою очередь усложняет поддержку и увеличивает вероятность ошибок.
РЕКОМЕНДУЕТСЯ следовать принципам GRASP.
6. Антишаблоны проектирования
ActiveRecord объединяет сущности, представляющие домен вместе с инфраструктурой, в виде логики работы с базой данных. Такое поведение нарушает принципы SRP и ISP из SOLID, и приводит к следующим последствиям.
Проблема Singleton заключается в том, что состояние объекта, как правило, хранится в статическом свойстве, и является не явным аргументом метода, или функции, см. пункт 4.10. данных рекомендаций.
Каждый метод (функция) ДОЛЖНЫ быть покрыты тестами для всех возможных вариантов выполнения метода (функции).
7.2. Стратегия тестирования
Код ТРЕБУЕТСЯ покрывать, согласно «белому ящику». В случае чрезмерной сложности использования «белого ящика» СЛЕДУЕТ использовать стратегию «черного ящика».
7.3. Разделение тест методов
Каждый тест метод ДОЛЖЕН иметь полностью независимое состояние, относительно других тест методов. Каждый тест метод ДОЛЖЕН проверять конкретное поведение тестируемого метода (функции), тест методы, которые проверяют несколько аспектов поведения НЕДОПУСТИМЫ.
Принцип DRY для тестов не применяется, что бы минимизировать ложно позитивные и ложно негативные результаты.
7.4. Тестируемый объект
7.5. Проверка результатов
Проверку результатов НЕОБХОДИМО выполнять на тождество, т.е. и на тип и на значение. Числа с плавающей точкой ДОЛЖНЫ проверяться с учетом погрешности. Значения времени, зависящие от текущего времени ДОЛЖНЫ проверяться с учетом погрешности.
8.1. Именование тестовых классов
Тестовый класс ДОЛЖЕН состоять из префикса Test и названия тестируемого класса.
8.1. Именование тест методов
8.2. Структура теста
Каждый тест ТРЕБУЕТСЯ оформлять согласно структуре, описанной ниже (каждый блок отделяется от остальных пустой строкой).
ДОПУСКАЕТСЯ отклонение от данной структуры, в случае, если полное следование ей невозможно. Например, когда значение переменной [3] определяется только после вызова конструктора тестируемого класса [6].
8.3. Переменные, используемые в тесте
Переменные, используемые в тесте ДОЛЖНЫ следовать следующим правилам.
Mock-объект ДОЛЖЕН быть объявлен, согласно следующим правилам.
8.5. Инкременты вызовов mock-объектов
8.6. Поведение методов mock-объектов
Поведение методов mock-объектов ДОЛЖНО описываться согласно одной из следующих структур.
8.7 Порядок утверждений для одного значения
В случае когда для проверки одного значения требуется несколько утверждений, эти утверждения ДОЛЖНЫ быть описаны в порядке от максимально информативных до минимально информативных, далее от общих к частным.
8.8. Проверка утверждений на основании результатов собственных проверок
Проверка утверждений на основании результатов собственных проверок ДОПУСКАЕТСЯ только в случае, когда отсутствует assert* метод, включающий эту проверку. Во всех остальных случая НЕОБХОДИМО использовать assert* метод.
Распространенной ошибкой является «ручная» проверка значения и утверждение о ее ложном, или положительном результате. В следствии такого подхода, срабатывание утверждения не покажет информацию о том, что же пошло не так.
8.9. Проверки значений на основании TestCase::callback
8.10. Проверка утверждений для числовых значений
Для проверок числовых значений с учетом погрешности ДОЛЖЕН использоваться метод assertEqual с обязательным указанием погрешности.
8.11. Проверка утверждений для \DateTimeImmutable
Для проверок \DateTimeImmutable зависящих от текущего времени ДОЛЖЕН использоваться метод assertEqual с обязательным указанием погрешности.
В случае проверок данных на основании текущего времени высока вероятность ложно позитивных и ложно негативных результатов. Дело в том, что сам процесс выполнения теста требует некоторого времени, как результат это время является неявной и не контролируемой переменной в тесте.
Для разработки php проектов РЕКОМЕНДУЕТСЯ использовать PhpStorm.
9.1. Inspections и Code Style