Laravel по-русски

Давным давно, когда люди забивали гвозди использую ASM и готовили DOS на Quick C...
О чём это я? А!
Да, есть такое понятие как "Коммерческий код". Это некая форма стилизации кода для лучшего восприятия кода мозгом.
Такой вид форматирования сильно облегчает понимание сути описанного в коде алгоритма.
К сожалению о нём забили, а многие даже и не слышали.
Данный вид форматирования был создан группой людей (из FidoNet). Использовался он для написания коммерческих программ, которые продаются вместе с исходным кодом.
На сегодняшний день почти все используют PSR и не задумываются о таких вещах, как скорость восприятия чужого кода на интуитивном уровне.
Вот и хочу Вам... рассказать... или напомнить... или предложить стиль кода "Коммерческий".
Чем он отличается и какие правила он применяет:

Большинство пишет код так:

class Text {
    const TEST = 1;
    
    public static $test = '';
    public $filename = '';
    public $name = '';
    private $a;
    protected $b;

    public functuion getA() {
        if(self::$test == self::TEST) {
            return $this->a;
        }
        /* Или такой вариант
        if (self::$test == self::TEST) {
            return $this->a;
        }
        */
        return null;
    }
}

Коммерческий код выглядит так:

class Text 
{
    // Константы всегда в начале
    const TEST = 1;
    
    // Затем всегда паблик    
    public $filename = '';
    public $name     = '';
    
    // Потом протектед
    protected $b;

    // и приватные
    private $a;

    // Далее так же и статические
    public static $test = '';

    // Такое же правило относится и к методам
    public functuion getA() 
    {
        // Обязательно if( пробел условие пробел )
        // if( - мозг воспринимает лучше чем if (
        // условия типа
        // if(!$data) или if (! $data)
        // воспринимается хуже чем if( !$data )
        if( self::$test == self::TEST ) {
            return $this->a;
        }

        return null;
    }
}

все переменные и свойства в snake_case
все методы в lowerCamelCase
все функции (процедуры) в snake_case
все имена классов в UpperCamelCase

описание последовательности вызова методов:
    return $users->default()
                 ->actived()
                 ->get();

а не:
    return $users->default()->actived()->get();

все простые условия типа:
    if( self::$test == self::TEST ) {
        return $this->a;
    }

    return null;

должны описываться так:
    return ( self::$test == self::TEST ) ? $this->a : null;

почему скобки? для визуального отделения условия от логики;
При длинных вариантах:
    return ( self::$test == self::TEST ) ? $users->default()->actived()->get() : $users->actived()->get();

Надо писать так:
    return ( self::$test == self::TEST )
               ? $users->default()->actived()->get()
               : $users->actived()->get();

Это будет восприниматься быстрей и понятней.

Я часто встречаю записи такого вида и они просто неудобно-читабельны:
    return $this->response($this->presenter->full($infraction));
или:
    $infraction->users()->attach($original->users->pluck('id'));

И исправляю их на:
    return $this->response(
        $this->presenter->full(
            $infraction
        )
    );
и:
    $infraction->users()
               ->attach(
                   $original->users
                            ->pluck('id')
               );

Так воспринимается куда более быстрей.

Много всего, но Коммерческий код воспринимается всеми программистами (и профи и новичками) с одинаковой скоростью и лёгкостью.
Что скажете?

Отлично написано! Респект автору!

Но всё же есть некие... так сказать "несогласия":
1. Название переменных и свойств классов таки правильней писать в snake case. И это не только на PHP. Но на PHP принято всеми. Lower Camel Case всё же для методов.
2. Вот здесь:
   $category->article()->create($request()->all());
Тоже не согласен. В большинстве простых случаем это Верно, но частенько бывает необходимость расставлять значения по условиям.
Если не заполнено это поле и заполнено то поле, значит значение в 1... А если не заполнены оба, значит 2... или если заполнено То без Этого, значит 3...
Таких примеров масса в средних и больших проектах и тогда обработку, и приведение данных правильней (на мой взгляд) делать в контроллере... ведь он для этого и создан.
тогда получается что-то вроде:
$category->article()->create([
   'title' => $request->title,
   'date' => $request->date ? $request->date : now(),
]);

Короткий и читаемый синтаксис.
Да и более того, в Laravel каждый раз добавляется много хелперов которые мало документированы... изучайте код.
Или создавайте свои хелперы типа:

    if( !function_exists('is_auth') ) {
        function is_auth()
        {
            return auth()->check();
        }
    }

    if( !function_exists('is_ajax') ) {
        function is_ajax()
        {
        return \Request::ajax();
          }
    }

Добавлю ещё пару-тройку хелперов авторизации:
auth()->check(); // \Auth::check();
auth()->user();
auth()->id();

И добавлю от себя...
- "Правильное описание модели и связанных с ней релейшенов это уже 30% приложения!"

На Laravel пишу где-то года 3. На PHP больше 10 лет. В основном Backend с MySQL (MariaDB), но есть опыт с jQuery + Bootstrap. Хочется найти интересный проект и приятную команду. Живу в Домодедово (Московская область), езжу на авто. Желательно не дальше полутора часов езды.
Хочется найти работу на долгие годы.