Вспомните, как в школе у вас были тетрадки в клетку и в линейку — для разных предметов свои. На уроках математики вы аккуратно писали «2 + 2 = 4», размещая каждый знак в отдельной клетке. Оставляли пару строк между задачами, чтобы всё выглядело опрятно и не сливалось.
Когда вы стали старше, то преподаватель просил оформлять работы определённым образом: использовать определённый шрифт, выделять заголовки, проставлять нумерацию страниц и вставлять колонтитулы. Возможно, вы считали, что это подавляет индивидуальность, но делалось это не просто так.
Единый формат облегчает чтение, проверку и сравнение. Представьте: каждая работа оформлена по-разному. Кто-то пишет в клетку, кто-то — в линейку, а кто-то и вовсе на белом листе, без разметки. Сколько бы времени ушло только на то, чтобы «вникнуть» в текст? Выглядели бы вычисления по математике на листе в линейку красиво? Конечно же, нет.
Так и с кодом. Когда в Google внедрили единый стиль кодирования, время прохождения ревью сократилось на 30%. Это не значит, что программисты стали умнее, а потому что перестало мешать оформление.
Но форматирование кода не преподают, не снижают оценки при обучении и на него вообще не обращают внимания.
Рассмотрим небольшой фрагмент кода:
// Плохо [✗]
class BlipController extends Controller {
public function index (){
$blips=Blip::with('user')->latest()->get() ;
return view( 'blips.index',[
'blips' => $blips] );
}
public function update(Request $request , Blip $blip) {
$blip->update($request->validated());
return redirect()->route('blips.index');}
}Код рабочий, синтаксических ошибок нет. Но посмотрите внимательнее: уже на двух методах видно, что стиль гуляет — лишние пробелы, где-то отступ есть, где-то нет, скобки кто как поставил. Это создаёт ощущение небрежности и усложняет чтение.
Исправить это — дело пары минут. И чем раньше вы начнёте обращать внимание на такие детали, тем легче будет работать с вашим кодом — вам и другим.
У каждого разработчика со временем формируются свои привычки. Один любит писать скобки на той же строке, другой — на новой. Один ставит пробел перед скобкой, другой считает это дурным тоном. Всё это — дело вкуса.
Но вот в чём загвоздка: вкусы у всех разные, а кодовая база — одна.
Допустим, в проекте работают два разработчика. Каждый оформляет код по-своему:
extends Controller
{
// ...
}extends Controller {
// ...
}Оба уверены в правильности своего стиля и могут привести весомые аргументы. Но код — это общее пространство. Здесь важнее не то, чей стиль «красивее», а то, чтобы он выглядел так, как будто его писал один человек. Даже если над ним работают пятнадцать разработчиков. Кому-то придётся уступить — это нормально.
Отнеситесь к этому как к государственной форме документа. Есть определённый шаблон, единый для всех граждан. Неважно, нравится ли шрифт, цвет или размер бумаги — важно, чтобы стиль был единым.
Если язык программирования достаточно зрел, скорее всего, у него есть общепринятые стандарты.
Например, для PHP есть PSR-12 и основанный на нём PER — PHP Extended
Recommendation.
Все эти стандарты охватывают очень большое количество аспектов оформления кода, включая отступы, пробелы, переносы строк, скобки, длину строки и многое другое.
Возможно, сначала будет непривычно, но вы быстро привыкнете и перестанете замечать отступы и переносы, сосредоточившись на содержимом.
Как же тогда это внедрить? Не писать же комментарий коллеги на каждую строчку кода в ревью?
Это отнимет слишком много времени и превратится в абсурд. На самом деле — это одна из самых простых практик в этой
книге.
Потому что уже есть множество инструментов автоматизации, например, Laravel Pint или PHP-CS-Fixer, которые будут
автоматически исправлять код:
// Хорошо [✓]
class BlipController extends Controller
{
public function index()
{
$blips = Blip::with('user')->latest()->get();
return view('blips.index', [
'blips' => $blips,
]);
}
public function update(Request $request, Blip $blip)
{
$blip->update($request->validated());
return redirect()->route('blips.index');
}
}Очень часто всё заканчивается полумерой: «Обязательно запускай линтер перед каждым коммитом!» и добавляют проверку в CI. Вроде разумно. Но это как просить студентов самостоятельно проверять орфографию на экзамене.
Разработчик отправил код и ушёл на обед, надеясь, что когда вернётся — получит верификацию и, может быть, ревью. Но, вернувшись, он видит: тесты не прошли. Линтер упал из-за пробела в конце строки. Смешно? Нет. Просто глупо.
Можно, конечно, в очередной раз напомнить: «Проверь перед коммитом», «Запусти линтер вручную», «Не забудь отформатировать». Но зачем? Если это можно делегировать машине — пусть делает она. Без напоминаний. Без обсуждений.
Это всё равно что зайти на Госуслуги и увидеть форму для входа, где можно ввести в свободное поле СНИЛС или номер телефона. Который можно ввести по-разному:
89512345678,+79512345678,9512345678,+7(951)234-56-78- и ещё множество вариантов.
Было бы странно, если бы где-то внизу было сказано: «Если вы вводите номер телефона, вводите его строго в формате XXX». Сайт заботится о пользователе и сам стандартизирует ввод, приводя ваш номер к единому формату.
Поведение должно быть аналогичным: разработчик отправил код. Линтер в CI автоматически привёл его в порядок. После этого — запустились тесты. Всё прошло. Разработчик спокойно обедает. Команда работает. Никто не отвлекается на ерунду.
Вот что по-настоящему эффективно. Не заставляйте разработчика думать об этом вовсе. Не возвращайте его к коду из-за пробела, скобки, пустой строки. Это абсурд.
Пусть он думает о логике. Об архитектуре. О том, за что его на самом деле наняли.