Laravel Pint: Настройка базовой конфигурации

Ранее я писал о выпуске Laravel Pint. По умолчанию он будет следовать стандарту laravel из коробки, стандарту команды Laravel.

• Laravel Pint — средство исправления стиля кода

Но что делать, если мы хотим чего-то другого? Давайте немного углубимся.

Если вы читали документацию, она очень информативна в отношении того, что вы можете делать с Laravel Pint. Вы можете реализовать множество правил в удобном JSON файле. Но какие из них работают хорошо, и что вам следует сделать?

Я собираюсь привести вас через свою конфигурацию Laravel Pint и объяснить, почему я выбрал эти настройки.

Рассматриваемый фрагмент конфигурации:

{
    "preset": "psr12",
    "rules": {
        "align_multiline_comment": true,
        "array_indentation": true,
        "array_syntax": true,
        "blank_line_after_namespace": true,
        "blank_line_after_opening_tag": true,
        "combine_consecutive_issets": true,
        "combine_consecutive_unsets": true,
        "concat_space": true,
        "declare_parentheses": true,
        "declare_strict_types": true,
        "explicit_string_variable": true,
        "final_class": true,
        "final_internal_class": false,
        "fully_qualified_strict_types": true,
    }
}

Выравнивание многострочных комментариев

Правило align_multiline_comment позволяет исправить любые комментарии, которые я называю скукоженные. Они не выровнены и выглядят странно. Это не относится к коду, но раздражает при чтении, поскольку ваши глаза будут прикованы к нему, а не к тому на чём хотите сосредоточиться.

Отступ массива

Правило array_indentation исправляет любые создаваемые вами массивы, который по какой-то причине стали скукоженными. Ещё одно правило очистки кода убирающее пробелы используемые не в том месте и т.д.

Синтаксис массива

Правило array_syntax может не понадобится, в зависимости от возраста вашего кода. Оно изменит старый синтаксис array(), на новый []. Я держу его на случай, если у меня встретится старый код или я работаю с несколькими разработчиками, у которых могут быть старые привычки.

Пустая строка после Namespace

Правило blank_line_after_namespace — вспомогательное правило, чтобы убедиться, что под объявлением namespace всегда есть пустая строка.

Пустая строка после открытия тега

Правило blank_line_after_opening_tag похоже на предыдущее, но требует пустой строки открывающегося PHP тега. Мне нравится, когда мой код организован и единообразен — эти правила позволяют сделать это.

Объединить последовательные isset

Правило combine_consecutive_issets научило меня использовать более одного аргумента проверки isset, что было для меня чем-то новым. Это преобразует любой код, объединяющий одну или несколько проверок isset, в одну чистую проверку.

// до
if (isset($a) && isset($b))

// после
if (isset($a, $b))

Объединить последовательные unset

Правило combine_consecutive_unsets похоже на предыдущее. Я не знал, что могу делать так, и это позволяет мне улучшать код.

// до
unset($a);
unset($b);

// после
unset($a, $b);

Отступы конкатенации

Правило concat_space — одно из моих любимых. Оно устанавливает пробелы между любой конкатенацией строк. Мне нравится, когда в коде есть свободное место, а не сжато.

// до
$name = $request->get('name');
$message = 'Hello '.$name;

// после
$message = 'Hello ' . $name;

Скобки объявлений

Правило declare_parentheses почти противоположно предыдущему правилу. Везде, где я использую оператор declare, я хочу убедиться, что вокруг него нет лишних пробелов.

// до
declare( strict_type = 1 );

// после
declare(strict_types=1);

Объявление строгих типов

Правило declare_strict_types для меня обязательно. Учитывая количество типов, которые используются в коде, хотелось бы убедиться, что строгая типизация включена. Это удобное правило, позволяющее принудительно добавить строгую типизацию без напоминаний. Отлично подходит для Laravel!

declare(strict_types=1);

Явная строковая переменная

Мне нравится добавлять правило explicit_string_variable — оно значительно упрощает чтение кода. Везде, где используются неявные переменные в коде, оно сделает их явными, как показано ниже.

$name = 'Steve';

$implicit = "Hello, $name";
$explicit = "Hello {$name}";

Финальный класс

Правило final_class — то из-за чего я буду преследовать Michael Dyrynda. Оно заставляет все ваши классы быть финальными в приложении. Однако будьте осторожны, так как это сделает каждый класс финальным, что может привести к поломкам при использовании Pest или расширении базового Контроллера в Laravel. К счастью, я не слишком беспокоюсь об этом, так как не использую много наследования.

Финальный внутренний класс

Правило final_internal_class — способ борьбы с вышеуказанным правилом. Если вы не хотите, чтобы класс был финальным, потому что планируете его расширять, убедитесь, что в вашей конфигурации для этого правила установлено значение false. Это сообщит игнорировать их и что внутренние классы не должны быть финальными.

{
  "final_internal_class": false
}

Полноценные строгие типы

Правило fully_qualified_strict_types заставляет вас импортировать класс как выражение use вместо объявления полного имени класса в качестве типа в методах и т.д. Это сохранит код чистым, а чистый код — счастливый код.

// до
public function __invoke(\Illuminate\Http\Request $request)

// после
public function __invoke(Request $request)

Есть ещё много используемых мной правил, поэтому вместо того, что бы утомлять вас каждым из них, я поделюсь своей конфигурацией. Так же загляните на сайт PHP CS конфигурации, для ознакомления с правилами и что они делают.

Вот моя текущая конфигурация, но имейте в виду, я часто настраивают её так как считаю, что стандарты кода должны быть живыми. Это должно быть что-то новое, что вы постоянно переоцениваете и смотрите, соответствует ли оно вашим потребностям.