Analyze roistat php-code-conventions

[index0h]

https://github.com/roistat/php-code-conventions

• Правила разделения бизнес-логики
• Часто упоминаемые объекты именуются одинаково во всем проекте
• Признак объекта добавляется к названию
• Переменные, отражающие свойства объекта, должны включать название объекта
• Переменные по возможности должны называться на корректном английском
• К переменной нельзя обращаться по ссылке (через &)
• Нельзя изменять переменные, которые передаются в метод на вход
• Нельзя нескольким переменным присваивать одно и то же значение
• Нельзя использовать константы через метод constant
• Названия boolean методов и переменных должны содержать глагол is, has или can
• Запрещены отрицательные логические названия
• Не используйте boolean переменные (флаги) как параметры функции
• Для конкатенации массивов запрещено использовать оператор +.
• Для проверки наличия ключа в ассоциативном массиве используем array_key_exists, а не isset
• Нельзя смешивать в массиве строковые и числовые ключи
• Для проверки наличия значения по индексу в обычных (не ассоциативных) массивах используем count($array) > N
• Строки обрамляются одинарными кавычками
• Вместо лишней конкатенации используем подстановку переменных в двойных кавычках
• Название метода должно начинаться с глагола и соответствовать правилам именования переменных.
• Методы названия, которых начинаются c check и validate, должны выбрасывать исключения и не возвращать значения
• Использование рекурсий допускается только в исключительном случае
• Запрещается кешировать данные в статических переменных метода
• Nullable параметры должны быть помечены ?, даже если указано значение по умолчанию.
• Метод всегда должен возвращать только одну структуру данных (или null) или ничего не возвращать
• Если метод возвращает один объект (или скалярный тип), то в случае, если объект не найден, возвращается null
• В больших методах возвращаемая переменная должна называться $result
• Метод должен явно отличать нормальные ситуации от исключительных
• Метод должен придерживаться следующей структуры: Проверка параметров → Получение данных → Работа → Результат
• Трейты имеют постфикс Trait
• Интерфейсы имеют постфикс Interface
• Абстрактные классы имеют префикс Abstract
• Все объекты должны быть неизменяемыми (immutable), если от них не требуется обратного
• Статические вызовы можно делать только у самого класса. У экземпляра можно обращаться только к его свойствам и методам
• В общем случае комментарии запрещены
• Вынужденные хаки должны быть помечены комментариями
• Готовые алгоритмы, взятые из внешнего источника, должны быть помечены ссылкой на источник
• При разработке прототипа допустимо помечать участки кода @todo
• По умолчанию тексты исключений не должны показываться пользователю
• Назначение всех числовых литералов должно быть понятным из контекста
• В условном операторе должно проверяться исключительно boolean значение
• В сравнении не boolean переменных используется строгое сравнение с приведением типа (===), автоматическое приведение и нестрогое сравнение не используются
• Не надо сравнивать boolean с true/false
• Проверять переменные надо на наличие позитивного вхождения, а не отсутствие негативного
• Тернарный оператор следует использовать, если обе ветви условия предназначены для установки одной переменной одним языковым выражением