Главная цель Code Conv — сохранение низкой стоимости разработки и поддержки кода на длинной дистанции.
Основные ценности, помогающие достичь этой цели:
Читаемость
Код должен легко читаться, а не легко записываться. Это значит, что такие вещи как синтаксический сахар (если он направлен на ускорение записи, а не дальнейшего чтения кода) вредны. Обратите внимание, что быстродействие кода не является ценностью, поэтому не самый оптимальный цикл, но удобный для понимания, будет лучше, чем быстрый, но сложный. Не нужно экономить переменные, буквы для их названий, оперативную память и так далее.
Вандалоустойчивость
Код надо писать так, чтобы у разработчика, который с ним будет работать, было как можно меньше возможности внести ошибку.
Поддержание наименьшей энтропии
Энтропия — это количество информации, из которой состоит проект (информационная емкость проекта). Код проекта должен выполнять продуктовые требования с сохранением наименьшей возможной энтропии.
Принципы — это способы соблюдения описанных выше ценностей. Они чуть более детальны, содержат основные методологии разработки и подходы, которыми мы руководствуемся.
Код должен быть:
- Понятным, явным. Явное лучше, чем неявное. Например, не должны использоваться магические методы. Также нельзя использовать
exitи любые другие операторы, которые могут завершить или изменить работу процесса. - Удобным для использования сейчас
- Удобным для использования в будущем
- Должен стремиться к соблюдению принципов KISS, SOLID, DRY, GRASP
- Код должен обладать низкой связанностью и высокой связностью (подробно это описано в GRASP). Любая часть системы должна иметь изолированную логику и при надобности внешний интерфейс, который позволяет с этой логикой работать. Любая внутренняя часть должна иметь возможность быть измененной без какого-либо ущерба внешним системам
- Код должен быть таким, чтобы его можно было автоматически отрефакторить в IDE (например, Find usages и Rename в PHPStorm). То есть должен быть слинкован типизацией и PHPDoc'ами
- В БД не должны храниться части кода (даже названия классов, переменных и констант), так как это делает невозможным автоматический рефакторинг
- Последовательным. Код должен читаться сверху вниз. Читающий не должен держать что-то в уме, возвращаться назад и интерпретировать код иначе. Например, надо избегать обратных циклов
do {} while (); - Должен иметь минимальную цикломатическую сложность
Если код можно убрать, и работа системы от этого не изменится, его быть не должно.
Плохо:
if (false) {
legacyMethodCall();
}
// ...
$legacyCondition = true;
if ($legacyCondition) {
finalizeData($data);
}Хорошо:
// ...
finalizeData($data);0 и пустую строку нельзя использовать в качестве показателя отсутствия значения.
function log(string $title, ?string $message = null, ?string $date = null): void {
// ...
}
// сообщение не было передано
$object->sendEmail('Title', null, '2017-01-01');
// было передано пустое сообщение
$object->sendEmail('Title', '', '2017-01-01');Однако, это правило не относится к массивам.
Плохо:
function deleteUsersByIds(array $ids = [], bool $someOption = false) {
// ...
}
deleteUsersByIds(null, true);Хорошо:
deleteUsersByIds([], true);Итого: использование пустой строки почти всегда является ошибкой.
Сервис – это класс без состояния, содержащий бизнес-логику. Данные для обработки сервис получает либо в виде параметров публичных методов, либо других сервисов.
Сервис не может использовать в качестве источника данных глобальные переменные или окружение:
Плохо:
class User {
public function loadUsers() {
$path = getenv('DATA_PATH'); // так нельзя!
// ...
}
}Хорошо:
class Env {
public function getDataPath(): string {
return getenv('DATA_PATH');
}
}
class User {
/**
* @var Env
*/
private $_env;
public function __construct(Env $env) {
$this->_env = $env;
}
public function loadUsers() {
$path = $this->_env->getDataPath();
// ...
}
}Однако, это правило не работает, если получение данных из внешних источников — единственная бизнес-логика сервиса.
Модель — простой объект со свойствами, не содержащий никакой другой бизнес-логики, кроме геттеров и сеттеров. Геттер — метод, позволяющий получить какую-то информацию из внутреннего состояния объекта. Это не обязательно поле, как оно есть. Он может брать значения нескольких полей и делать простые манипуляции с ними (не запрашивая внешней продуктовой бизнес-логики). Сеттер — аналогично может изменять внутреннее состояние одного или нескольких полей без запросов «наружу».
Условный упрощенный пример:
class Bill {
public $id;
public $sum;
public $isPaid;
public $paidDate
// ...
public function markAsPaid(\DateTime $paymentDate) {
$this->isPaid = true;
$this->paidDate = $paymentDate;
}
}Кроме случаев, когда внутри файла содержится класс. В таком случае файл должен повторять названия класса, то есть должен быть написан в стиле UpperCamelCase. Аналогично обычные директории и пространства имён.
Нельзя писать короткие названия, например $c. Нельзя назвать переменную $day и хранить в ней массив статистических данных за этот день.
Плохо:
$customer = new User();
$client = new User();
$object = new User();Хорошо:
$user = new User();Если это отфильтрованный по какому-то признаку проект, то признак добавляется к названию. Например, $unpaidProject.
Плохо:
$project = new Project();
$name = $project->name;
$project = $project->name;Хорошо:
$project = new Project();
$projectName = $project->name;Плохо:
$usersStored = [];Хорошо:
$storedUsers = [];Исключение: сгруппированные по некому признаку поля или константы. В этом случае можно использовать префикс.
class ProjectInfo {
const STATUS_WORKING = 1;
const STATUS_STOP = 2;
public $groupId;
public $groupAccessToken;
public $groupSettings;
}Амперсанды могут использоваться только как логические или битовые операторы.
Плохо:
function removePrefix(string &$name) {
// ...
}Хорошо:
function removePrefix(string $name): string {
// ...
return $result;
}📖 Переменные и свойства объекта должны являться существительными и называться так, чтобы они правильно читались при использовании, а не при инициализации.
Плохо:
$object->expire_at
$object->setExpireAt($date);
$object->getExpireAt();Хорошо:
$object->expiration_date;
$object->setExpirationDate($date);
$object->getExpirationDate();Нельзя писать $projectsArray, надо писать просто $projects. Это же касается и форматов (JSON, XML и т.п.), и любой другой не относящейся к предметной области информации.
Плохо:
$projectsList = $repository->loadProjects();
$projectsListIds = $utils->extractField('id', $projectsList);Хорошо:
$projects = $repository->loadProjects();
$projectsIds = $utils->extractField('id', $projects);Исключение — если эта переменная объект.
Плохо:
function parseText(string $text) {
$text = trim($text);
// ...
}Хорошо:
function parseText(string $text) {
$trimmedText = trim($text);
// ...
}Плохо:
$foo = false; $bar = true;Хорошо:
$foo = false;
$bar = true;Плохо:
function loadUsers(array $ids) {
$usersIds = $ids;
// ...
}Также можно использовать clone, если без него код серьёзно усложнится, а с ним станет понятным и очевидным. Простой пример — клонирование объектов DateTime. Или использование клонирования для сравнения двух версий объекта: старой и новой.
Плохо:
function loadAnalyticsData(\DateTime $intervalStart) {
$intervalEnd = new \DateTime($intervalStart->format('Y-m-d H:i:s'));
$intervalEnd->modify('+1 day');
}
function updateUser(User $user) {
$oldUser = new User();
$oldUser->id = $user->id;
$oldUser->name = $user->name;
// ...
logObjectDiff($user, $oldUser);
}Хорошо:
function someLogic(\DateTime $intervalStart) {
$intervalEnd = clone $intervalStart;
$intervalEnd->modify('+1 day');
}
function updateUser(User $user) {
$oldUser = clone $user;
// ...
logObjectDiff($user, $oldUser);
}Плохо:
$foo = $bar = strlen($someVar);Хорошо:
$bar = strlen($someVar);
$foo = $bar;Плохо:
$this->_callSomeFunc($bar = strlen($foo));Хорошо:
$bar = strlen($foo);
$this->_callSomeFunc($bar);Плохо:
if (strlen($foo = json_encode($bar)) > 100) {
// ...
}Хорошо:
$foo = json_encode($bar);
if (strlen($foo) > 100) {
// ...
}Плохо:
public function getProjectDir(): string {
$prefix = 'ACME_';
$name = $prefix . 'PROJECT_DIR';
return constant($name);
}
public function getProjectDir(): string {
return constant('ACME_PROJECT_DIR');
}Хорошо:
public function getProjectDir(): string {
return ACME_PROJECT_DIR;
}Переменные правильно называть, описывая их содержимое, а методы — задавая вопрос. Если переменная содержит свойство объекта, следуем правилу признак объекта добавляется к названию.
Плохо:
$isUserValid = $user->valid();
$canGetReward = $object->getGetReward($user);Хорошо:
$userIsValid = $user->isValid();
$canGetReward = $object->canGetReward($user);Геттеры именуются аналогично переменным:
class User {
private $_isEnabled;
public function isEnabled() {
return $this->_isEnabled;
}
}Такое именование позволяет легче читать условия:
// if user is valid, then do something
if ($userIsValid) {
// do something
}Плохо:
if ($project->isInvalid()) {
// ...
}
if ($project->isNotValid()) {
// ...
}Хорошо:
if (!$project->isValid()) {
// ...
}
if (!$accessManager->isAccessAllowed()) {
// ...
}Флаг в качестве параметра это признак того, что функция делает больше одной вещи, нарушая принцип единственной ответственности (Single Responsibility Principle или SRP). Избавляйтесь от них, выделяя код внтури логических блоков в отдельные ветви выполнения.
Плохо:
function someMethod() {
// ...
$projectNotificationIsEnabled = $notificationManager->isProjectNotificationEnabled($project);
storeUser($user, $projectNotificationIsEnabled);
}
function storeUser(User $user, bool $isNotificationEnabled) {
// ...
if ($isNotificationEnabled) {
notify('new user');
}
}Хорошо:
function someMethod() {
// ...
storeUser($user);
if ($notificationManager->isProjectNotificationEnabled($project)) {
notify('new user');
}
}
function storeUser(User $user) {
// ...
}Обратите внимание, что array_merge все числовые ключи приводит к int, даже если они записаны строкой.
Плохо:
return $initialData + $loadedData;Хорошо:
namespace Service;
class ArrayUtils {
public function mergeArrays(array $array1, array $array2): array {
return array_merge($array1, $array2);
}
}
public function someMethod() {
return $this->_arrayUtils->mergeArrays($initialData, $loadedData);
}isset проверяет не ключ на его наличие, а значение этого ключа, если он есть. Это разные методы с разным поведением и назначением. Если вы хотите проверить значение ключа, то делайте это явно. Сначала явно проверьте наличие ключа через array_key_exists и обработайте ситуацию его отсутствия, затем приступайте к работе со значением.
Плохо:
function processRequestData(array $requestData) {
$data = [];
if (isset($requestData['project_key'])) {
// ...
}
return $data;
}Хорошо:
function processRequestData(array $requestData) {
$data = [];
if (array_key_exists('project_key', $requestData)) {
// ...
}
return $data;
}Допустимо использовать сокращенный вариант ??, с явным указанием дефолтного значения.
function getProjectKey(array $requestData) {
return $requestData['project_key'] ?? null;
}То есть не применяем разные встроенные в PHP инструменты. Приведем несколько очевидных примеров (однако, правило ими не исчерпывается):
Плохо:
$arr = [
'project_key' => 'foo',
'key' => 'bar',
'user_id' => 300,
];
uasort($arr);Плохо:
$arr = [
'project_key' => 'foo',
'key' => 'bar',
'user_id' => 300,
1 => 'value1',
2 => 'value2',
];
$arr[3] = 'value3';📖 Для проверки наличия значения по индексу в обычных (не ассоциативных) массивах используем count($array) > N
Плохо:
if (array_key_exists(1, $users)) {
// ...
}
if (isset($users[1])) {
// ...
}Хорошо:
if (count($users) > 1) {
// ...
}Двойные кавычки используются только, если:
- Внутри строки должны быть одинарные кавычки
- Внутри строки используется подстановка переменных
- Внутри строки используются спец. символы
\n,\r,\tи т.д.
Плохо:
$string = "Some string";
$string = 'Some \'string\'';
$string = "\t".'Some string'."\n";Хорошо:
$string = 'Some string';
$string = "Some 'string'";
$string = "\tSome string\n";Плохо:
$string = 'Object with type "' . $object->type() . '" has been removed';Хорошо:
$string = "Object with type \"{$object->type()}\" has been removed";📖 Все пространства имён должны быть подключены через use в начале файла. В самом коде не должно быть обратного слеша перед названием пространства имён
Плохо:
$object = new \Some\Object();Хорошо:
use Some;
$object = new Some\Object();Плохо:
use TimeZone;
$date = new TimeZone('Europe\Moscow');Хорошо:
$date = new \TimeZone('Europe\Moscow');Плохо:
use Entity\User;
use Entity\Project;
$user = new User();
$project = new Project();Хорошо:
use Entity;
$user = new Entity\User();
$project = new Entity\Project();Они запутывают код и его понимание. Если у вас совпадают названия пространств имён, то, скорее всего, вы делаете что-то не так. Допустимо использовать псевдоним, если другое решение будет слишком сложным.
Плохо:
use Component\User;
use Entity\User as UserEntity;
$user = new UserEntity();Хорошо:
use Component\User;
use Entity;
$user = new Entity\User();📖 Должна быть использована максимально возможная типизация для вашей версии PHP. Все параметры и их типы должны быть описаны в объявлении метода либо в PHPDoc. Возвращаемое значение тоже.
Плохо:
/**
* @param $id
* @param $name
* @param $tags
* @return mixed
*/
function storeUser($id, $name, $tags = []) {
// ...
}Хорошо:
// для PHP 7.1
function makeCoffee(string $type, int $volume): Coffee {
// ...
}
// в PHP 7.1 тип элементов массива в объявлении метода указать нельзя, поэтому добавляем PHPDoc
/**
* @param int $id
* @param string $name
* @param string[] $tags
* @return User|null
*/
function storeUser(int $id, string $name, array $tags = []): ?User {
// ...
}
// если метод возвращает смешанный тип данных, то необходимо явно это указать
/**
* @param callable $callback
* @return mixed
*/
function execute(callable $callback) {
// ...
}
// для PHP 5.6
// без строгой типизации возвращаемых типов любой метод
// может вернуть null, так что можно его не указывать в PHPDoc
/**
* @param int $id
* @param string $name
* @param string[] $tags
* @return User
*/
function storeUser($id, $name, array $tags = []) {
// ...
}Наибольшую пользу это приносит при работе с массивами:
Плохо:
/**
* @param array $users
* @param mixed $project
* @param int $timestamp
* @return mixed
*/
public function someMethod($users, $project, $timestmap) {
foreach ($users as $user) {
// IDE не сможет определить тип $user
}
// ...
}Хорошо:
/**
* @param Users[] $users
* @param Project $project
* @param int $timestamp
* @return Foo
*/
public function someMethod(array $users, Project $project, int $timestmap): Foo {
foreach ($users as $user) {
// подсказки IDE и рефакторинг работают корректно
}
// ...
}Плохо:
public function items() {
// ...
}
public function convertedDataObject(array $data) {
// ...
}Хорошо:
public function loadItems() {
// ...
}
public function convertDataToObject(array $data) {
// ...
}Например, вместо getDate() следует писать date(). Геттер — метод, работающий только с полями своего объекта.
Плохо:
class User {
private $_date;
private $_customFields;
public function getDate() {
return $this->_date;
}
public function getCustomFields() {
return json_decode($this->_customFields);
}
}Хорошо:
class User {
private $_date;
private $_customFields;
public function date() {
return $this->_date;
}
public function decodedCustomFields() {
return json_decode($this->_customFields);
}
}📖 Методы названия, которых начинаются c check и validate, должны выбрасывать исключения и не возвращать значения
Плохо:
public function validateRequestData(array $requestData): bool {
if (!array_key_exists('key', $requestData)) {
return false;
}
// ...
return true;
}Хорошо:
public function validateRequestData(array $requestData): void {
if (!array_key_exists('key', $requestData)) {
throw new ValidationError('Field "key" not found');
}
// ...
}Если метод используется наследниками класса, то он объявляется protected. Если используется сторонними классами, тогда public.
Если код без рекурсии будет очень сложен для написания и понимания и при этом рекурсия гарантированно не выйдет за ограничения стека вызовов.
Для кеширование в памяти используем свойство объекта.
Плохо:
public function loadData() {
static $_cachedData;
if ($_cachedData === null) {
$_cachedData = [];
}
return $_cachedData;
}Хорошо:
private $_cachedData = [];
public function loadData() {
if ($this->_cachedData === null) {
$this->_cachedData = [];
}
return $this->_cachedData;
}📖 Параметры в методах должны следовать в следующем порядке: обязательные → часто используемые → редко используемые
Нужно соблюдать читаемость при написании вызова.
Плохо:
public function method($required, $practicallyUnused = 5, $often = [], $lessOften = null)
public function filter($value, $name, $operator) // ...$service->filter(15, "id", "=")Хорошо:
public function method($required, $often = [], $lessOften = null, $practicallyUnused = 5)
public function filter($name, $operator, $value) // ...$service->filter("id", "=", 15)Плохо:
function f(int $number = null) {}Хорошо:
function f(?int $number = null) {}
function f(?int $number) {}Метод не может в разных ситуациях возвращать разные типы данных.
Плохо:
function loadUser() {
if ($someCondition) {
return ['id' => 1];
}
return new User();
}Хорошо:
function loadUser(): User {
if ($someCondition) {
$user = new User();
$user->id = 1;
return $user;
}
return new User();
}📖 Если метод возвращает один объект (или скалярный тип), то в случае, если объект не найден, возвращается null
Если же метод возвращает список объектов, то в случае, когда список пуст, возвращает пустой массив. Нельзя возвращать вместо пустого списка null.
Плохо:
function loadUsers() {
if ($someCondition) {
return null;
}
return [new User()];
}Хорошо:
/**
* @return User[]
*/
function loadUsers(): array {
if ($someCondition) {
return [];
}
return [new User()];
}Однако, бывают ситуации, когда надо явно указать, что данные отсутвуют, а не содержат пустой список.
Пример: значения полей объекта задаются пользователем. Возможны две ситуации:
- пользователь не знает, каким категориям принадлежит объект —
null - пользователь знает, что объект не принадлежит ни одной категории — пустой массив (
[])
Тогда для получения категорий объекта будет правильным такой код:
/**
* для PHP 5.6
* @return array|null
*/
function getObjectCategories($object) {
if ($object->categories === null) {
return null;
}
return parseCategories($object->categories);
}
// для PHP 7.1
function getObjectCategories($object): ?array {
if ($object->categories === null) {
return null;
}
return parseCategories($object->categories);
}Если у вас большой метод (больше 15 строк), возвращаемая переменная должна называться $result, если с ней могут
происходить изменения в середине работы метода.
В любом месте в методе должно быть понятно, где вы оперируете результатом, а где локальными переменными.
Плохо:
function loadUsers(): array {
$users = [];
// ... много кода, изменяющего переменную $users
return $users;
}Хорошо:
function loadUsers(): array {
$result = [];
// ... много кода, изменяющего переменную $result
return $result;
}Если никакой ошибки не произошло, но отсутствует результат, то это null (или пустой массив), однако если все же произошла исключительная ситуация, которая не заложена системой, то должно кидаться исключение.
Плохо:
function loadUsers(): array {
if ($connectionError !== null) {
return []; // потеряли ошибку, никто не узнает о проблемах с подключением
}
// ...
if (count($data) === 0) {
return [];
}
// ...
return $result;
}Хорошо:
function loadUsers(): array {
if ($connectionError !== null) {
throw new Exception\ConnectionError();
}
// ...
if (count($data) === 0) {
return [];
}
// ...
return $result;
}📖 Метод должен придерживаться следующей структуры: Проверка параметров → Получение данных → Работа → Результат
Во время проверки параметров и получения необходимых данных метод должен возвращать соответствующее пустое значение или кидать исключение. После того как метод получил все необходимые данные и приступил к работе выход из метода крайне нежелателен. Возможны редкие исключения, облегчающие понимание и читаемость кода.
Плохо:
public function someMethod(): int {
$isValid = $this->_someCheck();
if ($isValid) {
$tmp = 0;
$someValue = $this->_getSomeValue();
if ($someValue > 0) {
$tmp = $someValue;
}
$anotherValue = $this->_getAnotherValue();
if ($anotherValue > 0) {
return $tmp + $anotherValue;
} else {
return $someValue;
}
} else {
throw new \Exception('Invalid condition');
}
}Хорошо:
/**
* @throws \Exception
*/
public function someMethod(): int {
$result = 0;
$isValid = $this->_someCheck();
if (!$isValid) {
throw new \Exception('Invalid condition');
}
$someValue = $this->_getSomeValue();
if ($someValue > 0) {
$result += $someValue;
}
$anotherValue = $this->_getAnotherValue();
if ($anotherValue > 0) {
$result += $anotherValue;
}
return $result;
}Хорошо:
trait AjaxResponseTrait {
// ...
}Хорошо:
interface ApplicationInterface {
// ...
}Хорошо:
abstract class AbstractApplication {
// ...
}Если свойство используется наследниками класса, то оно объявляется protected. Если используется сторонними классами, тогда public.
Плохо:
abstract class Loader {
public $data = [];
public function getData() {
return $this->data;
}
public function init() {
$this->data = $this->load();
}
abstract public function load();
}Хорошо:
abstract class Loader {
/**
* @type array
*/
private $_cachedData = [];
public function getData(): array {
return $this->_cachedData;
}
public function init(): void {
$this->_cachedData = $this->_load();
}
abstract protected function _load(): array;
}📖 Методы и свойства в классе должны быть отсортированы по уровням видимости и по порядку использования сверху вниз
Уровни видимости: public -> protected -> private.
Плохо:
class SomeClass {
private $_privPropA;
public $pubPropA;
protected $_protPropA;
protected function _protA() {
}
public function pubB() {
}
private function _privA() {
return $this->_protA();
}
public function pubA() {
$this->_privA();
return $this->pubB();
}
}Хорошо:
class SomeClass {
public $pubPropA;
protected $_protPropA;
private $_privPropA;
public function pubA() {
$this->_privA();
return $this->pubB();
}
public function pubB() {
}
protected function _protA() {
}
private function _privA() {
return $this->_protA();
}
}Плохо:
class SomeObject {
/**
* @var int
*/
public $id;
}Хорошо:
class SomeObject {
/**
* @var int
*/
private $_id;
public function __construct(int $id) {
$this->_id = $id;
}
public function id(): int {
return $this->_id;
}
}📖 Статические вызовы можно делать только у самого класса. У экземпляра можно обращаться только к его свойствам и методам
Плохо:
$type = $user::TYPE;Хорошо:
$type = User::TYPE;Желание добавить комментарий — признак плохо читаемого кода. Любой участок кода, который вы хотели бы выделить или прокомментировать, надо выносить в отдельный метод.
Фразу, которую вы хотели написать в комментарии, надо привести в простой вид и сделать ее названием метода.
Плохо:
public function deleteApprovedUsers() {
// load users filter them by approval
$users = $repository->loadUsers();
array_filter($users, function($user) {
return $user->is_approved;
});
foreach ($users as $user) {
// ...
}
}Хорошо:
public function deleteApprovedUsers() {
$users = $this->loadApprovedUsers();
foreach ($users as $user) {
// ...
}
}
public function loadApprovedUsers(): array {
$users = $repository->loadUsers();
array_filter($users, function($user) {
return $user->is_approved;
});
}Лучше соблюдать одинаковый формат в рамках проекта
Хорошо:
function loadUsers(): array {
$result = $repository->loadUsers();
// hack: status field was removed from storage
foreach ($result as $user) {
$user->status = 'active';
}
// hack end
return $result;
}Хорошо:
/**
* https://en.wikipedia.org/wiki/Quicksort
*/
function quickSort(array $arr): array {
// ...
}
/**
* https://habrahabr.ru/post/320140/
*/
function generateRandomMaze() {
// ...
}Хорошо:
function loadUsers(): array {
$result = $repository->loadUsers();
// @todo: delete the hack when field will be restored
// hack: status field was removed from storage
foreach ($result as $user) {
$user->status = 'active';
}
// hack end
return $result;
}📖 На каждом уровне бизнес-логики (проект, компонент, библиотека) должно быть абстрактное базовое исключение
Далее либо обработаны, либо на их основании должно бросаться свое исключение. Новое исключение должно содержать предыдущее.
Хорошо:
namespace Service\Facebook;
use Exception;
use FacebookAds;
public function requestData() {
// ...
try {
$objects = $facebookAds->requestData($params);
} catch (FacebookAds\Exception\Exception $e) {
throw new Exception\ExternalServiceError("Facebook error", 0, $e);
}
//..
}Они предназначены для логирования и отладки. Текст исключения можно показать пользователю, если оно явно для этого предназначено: например, реализует интерфейс HumanReadableInterface.
interface HumanReadableInterface {
public function getUserMessage(): string;
}
public function handleException(\Throwable $exception): void {
if ($exception instanceof HumanReadableInterface) {
echo $api->sendMessage($exception->getUserMessage());
return;
}
// ...
}Плохо:
$users = loadUsers();
foreach ($users as $user) {
$userProjects = loadUserProjects($user);
// ...
}Хорошо:
$users = loadUsers();
$projects = loadProjects();
$indexedProjects = [];
foreach ($projects as $project) {
if (!array_key_exists($project->user_id, $indexedProjects)) {
$indexedProjects[$project->user_id] = [];
}
$indexedProjects[$project->user_id][] = $project;
}
foreach ($users as $user) {
if (!array_key_exists($user->id, $indexedProjects)) {
continue;
}
$userProjects = $indexedProjects[$user->id];
}То есть должна быть колонка date/creation_date. Или должен быть зависимый объект (связь 1 к 1), у которого есть такая колонка. Редактируемые записи должны иметь и дату редактирования: update_date или modification_date.
Любая атомарная часть кода должна выделяться в отдельную подзадачу и отдельный PR.
Перенос методов в другие классы и места должны быть выделены в отдельный PR. Последующий рефакторинг после переноса тоже должен быть в отдельном PR.
📖 В случае большого PR — ответственность за долгий просмотр несет сам разработчик, сделавший такой PR
Нормальный объем кода — 1-300 строк в зависимости от его сложности. PR заглушек и архитектуры может содержать много формального кода, который легко быстро проверить. PR же конкретного метода может содержать много сложностей даже в 10 строчках.
Все что можно смержить в master без последствий (даже если это еще не готовый результат, а только заглушки или часть, но они скрыты от юзеров и никому не мешают), должен мержиться в master и PR должен создаваться в master.
Также не должно быть забытых комментариев, бессмысленных переносов строк и прочего "строительного мусора". Каждое изменение, которое вы предлагаете сделать в master-ветке, должно так или иначе относиться к решению поставленной вам задачи.
Они должны быть или вынесены в переменную или константу, или сравниваться с переменной, или передаваться на вход методу с понятной сигнатурой. В коде должен присутствовать в явном виде ответ: за что отвечает это число и почему оно именно такое?
Плохо:
$isOnlyDeleted = 1;
if ($object->is_deleted === $isOnlyDeleted) {
// ...
}
for ($i = 0; $i < 5; $i++) {
// ...
}Хорошо:
$isOnlyDeleted = 1;
if ($object->is_deleted === $isOnlyDeleted) {
// ...
}
$apiMaxRetryLimit = 5;
for ($i = 0; $i < $apiMaxRetryLimit; $i++) {
// ...
} Плохо:
if (count($userProjects)) {
// ...
}
if ($project) {
// ...
}Хорошо:
if ($isResponseError) { // $isResponseError = true
// ...
}
if ($response->isError()) { // isError method returns boolean
// ...
}
if (count($userProjects) > 0) {
// ...
}📖 В сравнении не boolean переменных используется строгое сравнение с приведением типа (===), автоматическое приведение и нестрогое сравнение не используются
Плохо:
if ($project) {
// ...
}
if ($request->postData('sum') == 100) {
// ...
}
if (!$request->postData('sum')) {
// ...
}
if (!$bill->comment) {
// ...
}Хорошо:
if ($project === null) { // $project is an object
// ...
}
if ((int)$request->postData('sum') === 100) {
// ...
}
if ($bill->comment === '') {
// ...
}📖 Автоматическое приведение типов разрешено только, когда один из операндов — литерал с фиксированным типом
При сравнении двух переменных с неизвестными типами для читающего код человека не очевидно, к чему они будут приведены интерпретатором. Если же тип одного из операндов известен, то всё становится очевидно и ручное приведение типов не требуется.
Если вы хотите проверить значение boolean пришедшее извне, то делается это так:
Плохо:
if ((int)$request->get('is_something') > 0) {
// ...
}
if ((int)$request->get('is_something') === 1) {
// ...
}
if ((int)$user->is_registered === 0) {
// ...
}Хорошо:
if ($request->get('is_something') > 0) {
// ...
}
if ($user->is_registered) {
// ...
}
if (!$user->is_registered) {
// ...
}Это нарушает запрет на бесполезный код.
Плохо:
if ($bill->isPaid() == true) {
// ...
}
if ($bill->isPaid() !== false) {
// ...
}
if (!$bill->isPaid() === true) {
// ...
}
if (!(!$bill->isPaid() === true)) {
// ...
}
if ((bool)$phone->is_external === true) {
// ...
}Хорошо:
if ($user->isValid()) {
// ...
}Если вам нужна строка, то проверять надо на то, что переменная является строкой. Не надо проверять на то, что она не является числом или чем-то еще. Перечислять все возможные варианты, чем переменная не должна быть, значит повышать риск ошибки и усложнять поддержку кода.
Плохо:
if (!is_numeric($value) && !is_object($value)) {
// ...
}Хорошо:
if (is_string($value) && $value !== '') {
// ...
}📖 Если вы используете встроенную функцию PHP, которая возвращает 0, 1 и, возможно, false, то при возможности результат ее работы используем в условии как bool без дополнительных сравнений
Это не касается случая, когда вам нужно отделить два разных результата между собой, например отдельно отработать 0 и false.
Плохо:
if (preg_match($pattern, $subject) === 1) {
// ...
}
if (!strpos($search, $text)) {
// ...
}Хорошо:
if (preg_match($pattern, $subject)) {
// handle success
}
if (!preg_match($pattern, $subject)) {
// handle not success
}
if (preg_match($pattern, $subject) === false) {
// handle error
}
if (strpos($search, $text) === false) {
// handle not success
}📖 При использовании в условном выражении одновременно операторов И и ИЛИ обязательно выделять приоритет скобками
Обратите внимание на различие в значении двух вариантов правильного использования
Плохо:
if ($isMobile || $isSizeTooBig && $isAllowedToShrink) {
// ...
}Хорошо:
if (($isMobile || $isSizeTooBig) && $isAllowedToShrink) {
// ...
}
if ($isMobile || ($isSizeTooBig && $isAllowedToShrink)) {
// ...
}📖 Тернарный оператор следует использовать, если обе ветви условия предназначены для установки одной переменной одним языковым выражением
При наличии логики в ветках условия следует рассмотреть возможность вынести ее в отдельный метод.
Плохо:
if ($isExternal) {
$value = $this->loadSomething();
} else {
$value = $this->loadSomethingElse();
}Хорошо:
$value = $isExternal ? $this->loadSomething() : $this->loadSomethingElse();📖 Использовать цепочки из тернарных операторов ?: допустимо только при указании значения по умолчанию
Плохо:
$contact = $this->loadContactByPhone() ?: $this->loadContactByEmail() ?: $this->loadContactByName();Хорошо:
$contact = $this->loadContactByPhone() ?: $this->loadContactByEmail() ?: $this->loadContactByName() ?: null;📖 Любой скрипт, который изменяет данные, должен иметь подтверждение перед выполнением действий с данными и debug по результатам работы
Плохо:
// scripts/delete_items.php
$repository->deleteItems();Исправим, чтобы случайный запуск не удалил элементы:
Хорошо:
// scripts/delete_items.php
$totalItems = $repository->countItems();
if (!confirm("Do you want to delete {$totalItems} item(s)?")) {
echo 'Delete canceled, exit';
exit(1);
}
$repository->deleteItems();
function confirm(string $question): bool {
return readline("{$question} [y/n]: ") === 'y'
}