Как писать код так, чтобы он рос в высоту, а не в ширину

Каждый раз, когда мы добавляем в код новый if или for, приходится увеличивать отступ тела условия или цикла. Чем больше вложенных циклов и условий, тем шире становится код и начинаются трудности при его чтении. В этой небольшой заметке я покажу несколько приёмов благодаря которым можно избежать роста отступов, чтобы код был понятнее и чтобы в нём никогда не появлялась горизонтальная прокрутка.

Правило 0. Не слушай меня, слушай свой style guide
Прежде всего напомню о самом важном — стиле написания кода. Если вы работаете не один, а в команде, то вам важно писать код так, чтобы не переключаться со стиля на стиль при чтении кода (помните, над одним файлом может работать множество разработчиков). Поэтому вы должны согласовать стиль написания кода: как именовать переменные, сколько пробелов (или табов) в отступах, где ставить фигурные скобки и так далее. Если вы пишете код один, у вас всё равно может использоваться стиль кода, определённый создателями языка программирования или сообществом. Придерживайтесь его.


Правило 1. Ставьте else как можно ближе к своему if
Иногда листаешь код, глазами перескакиваешь с одного метода на другой, прокручиваешь и видишь это:
И вроде всё ничего, но стоит глазам опуститься к строке "} else {", впадаешь в ступор и задаёшься вопросом: если есть else, то каким был if? И приходится прокручивать код вверх, чтобы понять, что перед тобой это:

Можно инвертировать условие и поменять местами тело блока if и else так, чтобы тело if было короче тела else. Это избавит нас от висячих else, ступоров и прокруток вверх.


Правило 2. if/else можно заменить на if-return
В предыдущем коде можно уменьшить отступ блока else, если в конце блока if поставить return:

В данном случае return ничего не сломает, напротив, избавляет от лишней вложенности. Конечно, кому-то может быть неочевидно, что это на самом деле if/else, кто-то может быть против такого кода, считая, что у метода должен быть один вход и один выход. И будут правы, поэтому решение должен диктовать ваш style guide.

Этот же способ работает и с if/else if/else:


Хотя в данном случае отступ остаётся прежним, но зато однотипные блоки визуально лучше выделяются.


Правило 3. Внутри циклов if/else можно заменить на if-continue
Внутри циклов для удаления else следует использовать не return, а continue. Было так:

В конце тела ветки if добавляем continue и получаем работающий код с меньшим отступом:


Правило 4. Без надобности делать замену не стоит
Если код и так понятен, лучше ничего не трогать и оставить как есть, например:
не стоит заменять на:

Так читабельность только ухудшается.


Правило 5. Если уровень вложенности превышает допустимую отметку, вводите новый метод
Если случается так, что внутри одного метода так много вложенных циклов и условий, что код уехал вправо из-за отступов и вот-вот появится горизонтальная прокрутка, значит пора делать рефакторинг и заменять какую-либо часть метода другим методом. Например:

Даже не пытайтесь понять этот код, только потратите время. его я просто придумал для примера. Рефакторинг — тема отдельной статьи, поэтому поэтапно рассматривать этот процесс не стану. Суть именно в изменениях:

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