Не больше 8 строк на функцию. Каких правил форматирования придерживаются разработчики

«Какой программный код проще понять и читать — с отступами или без», — таким вопросом задался Flutter Developer Богдан Гончарук. Своим мнением на этот счет поделились пользователи LinkedIn. В опросе приняли участие почти 200 человек. 

Результаты опроса

Несмотря на то, что это одна из холиварных тем, согласно результатам опроса абсолютное большинство разработчиков, 95%, считают, что проще взаимодействовать с кодом с отступами. 

Результаты опроса

Такого мнения придерживается и Богдан Гончарук. Его доводы в первую очередь базируются на книге Стивена Макконелла «Совершенный код», в одной из глав которой говорится об исследовании среди разработчиков на восприятие кода. По его итогам были сделаны следующие выводы: 

• программный код, который был форматирован по правилам организации отступов, воспринимался тестируемыми на 20–30% лучше, чем слитный код;
• важно не переборщить с отступами и придерживаться какого-то определенного формата;
• самые низкие показатели понимания были у тех, кто работал с кодом вообще без отступов.

Не более 5–8 строк на функцию

В пользу кода с отступами выступают и авторы «Чистого кода», одной из самых популярных книг о его создании, анализе и рефакторинге. Ее процитировал Unity Developer Михаил Хаджинов. Он написал, что в книге есть четкий ответ на этот вопрос, который гласит примерно следующее: 

Ни одна функция не должна быть длиннее пяти-восьми строк. Функции большого размера трудно читать, модифицировать и тестировать. Да, сделать код компактным не всегда легко, но к этому нужно стремиться, главное — не делать это за счет увеличения плотности кода

Все в куче

Для наглядности автор предложил разобрать следующий пример. На нем код слева написан без каких-либо отступов, а справа — структурирован. 

Как лучше?

С таким подходом не совсем согласен .NET-разработчик Виталий Шмидт. По его мнению, отступы перед закрывающейся фигурной скобкой лишние. Гораздо удобнее, когда каждая конструкция отделяется от другой одной пустой строкой после закрывающейся фигурной скобки. Так тратится минимальное количество времени на прочтение код каждый раз, когда к нему возвращаешься, уверен Виталий. 

Но также он считает, что главное, чтобы код был выдержан и написан в едином стиле. То есть если в новом проекте по наследству достается большая кодовая база, где все написано по принципу «все в куче», нужно придерживаться общей структуры. 

Еще один вариант оформления кода

Структурировать код или нет — дело каждого и зависит от политики проекта, но если вы все же решили следовать правилам, то вот какие книги для этого можете почитать: 

• Стивена Макконелла «Совершенный код»;
• Роберт К. Мартин «Чистый код»;
• Эндрю Хант и др. «Программист-прагматик. Путь от подмастерья к мастеру»;
• Лео Броуди «Способ мышления — Форт»;
• Мартин Фаулер и др. «Рефакторинг, Улучшение существующего кода»;
• Роберт Нистром «Шаблоны игрового программирования»;
• Дастин Босуэлл «Читаемый код или программирование как искусство».

А каких стандартов форматирования придерживаетесь вы? Пишите об этом в комментариях.