Вложенность кода

Не для всех очевидно, что большая вложенность if'ов или других конструкций является какой-то проблемой. Но на самом деле, когда продукт большой, а подобных мест много - то это становится довольно ощутимой бедой. Далее будет условный пример "на кошках" так сказать, но вы представьте, что логика в разы сложнее, вызываются разные классы, методы и т.д.

Рассмотрим плохой пример...

Он даже без добавления логики выглядит уже сам по себе плохо - 6 уровней вложенности. При этом представьте, что между if'ами еще есть какие-то дополнительные if'ы и вызовы сторонних функций из сторонних библиотек...

Еще усложним...

Представьте, что логика там еще более ветвистая и сложная (как обычно и бывает в реальных проектах, даже если они не очень сложные).

Как же решать подобные вопросы... Есть один очень действенный подход - это инвертированные проверки, которые разительно сокращают вложенность вашего кода.

Давайте применим инвертированные проверки к этому "грязному" коду. Каждая проверка теперь будет отталкиваться от обратного, заведомо зная, что мы все равно должны прийти только в один сценарий.

Первым делом уберем все else'ы, потому что они нам не нужны и только растягивают код.

Else вообще можно не прописывать, если у вас в if прописан return.

Вторым делом - сделаем инверсию проверок. Мы переделали проверку переменной $a.

Далее мы переделали аналогичным образом проверки остальных переменных.

Таким образом мы получили вместо 6 уровней вложенности всего 1. Мы значительно повысили читаемость кода - его теперь намного проще читать и понимать что происходит. Мы получили более простую возможность контролировать возвращаемые параметры (не искать что же там return else'а делает на уровне вложенности 4 ).

На данном примере возможно выгода не так очевидна, но когда у вас проект уже большой, переменные называются не $a, а например $unholdedOperationsFromDwhSortedByTransactionTypeId и вызовов методов в разы больше - это сыграет огромнейшую роль при написании кода и при дальнейшей его поддержке.