Кто во время код-ревью не слышал, чтобы коллега говорил вам: «Пожалуйста, используйте фигурные скобки в одной строке с условием if, если нет, это нечитабельно», или наоборот: «Здесь мы ставим скобку после if, код более так понятнее», или классический: «Не используйте табуляции, используйте пробелы для отступа»… Я даже не говорю о аргументах вокруг этих «важных» правил, как будто ваш компилятор или ваш интерпретатор дал ах** * об этом при создании вашей программы.

Действительно, есть некоторые языки программирования, в которых пробел вместо табуляции может изменить поведение программы (нет, я не хочу говорить о белом языке программирования 😝), но большинству на это наплевать. И когда интерпретатор популярного языка программирования (да, Python, я думаю о вас) заботится об этом, тогда люди перестают спорить и кодируют с этими ограничениями.

Так почему же люди спорят об этом, когда им предлагают шанс? Есть ли хороший ответ на вопросы форматирования? И есть ли решение покончить с этим раз и навсегда? Об этом мы и поговорим в этой статье 😉

Зачем такая борьба?

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

Размер исходного кода

В галактике не так далеко и не так давно у компьютеров не было ни памяти, ни вычислительной мощности. 👵 Вы можете взять в качестве примера размер игры Super Mario Bros. по сравнению со скриншотом, сделанным на современном компьютере, чтобы увидеть разрыв между ними, или память, необходимая для отправки людей на Луну. Это популярные примеры, но вы легко можете себе представить, что, если бы у вас было всего 4 КБ памяти для запуска вашей программы, в то время ваш исходный код не хранился бы на жестком диске объемом 1 терабайт. Вы можете посмотреть IBM System/360, чтобы убедиться в малом пространстве, доступном на старых машинах.

Таким образом, в то время использование табуляции или пробелов могло иметь значение, поскольку табуляция вместо 2 или 4 пробелов во всей программе уменьшит размер вашего исходного кода; сохраняя скобку на той же строке, что и условие if, избегайте использования памяти для сохранения новой строки. Эти элементы складываются в программу, и в то время, когда память была такой дорогой и такой ограниченной, было важно, чтобы исходный код был коротким.

НО этого ограничения больше не существует. Для большинства проектов у вас не будет больше 1 ТБ исходного кода, так что все должно быть в порядке. 🙂

Читабельность

Кто хоть раз читал код, думал: «Кто это написал! Это не понятно!» и когда вы запускали на нем git blame, вы говорили: «О... это был я». Звучит знакомо, не так ли? Итак, теперь вам нужно потратить 5, 10, 15 или более минут, чтобы понять этот код, прежде чем смотреть и остальной код, который, вероятно, написан так же плохо.

Что делать, если вы ищете источник ошибки? Если вам повезет, у вас перед глазами будет происхождение жучка, и вам предстоит его расшифровать. Если нет, вы собираетесь расшифровать какой-то код, который даже не связан с ошибкой. Каким бы ни был ваш шанс, этот плохо написанный код лишил вас времени и денег (за то время, которое вы потратили на него).

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

Но что такое хорошо отформатированный код? На что это похоже ?

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

Но это не то, что должно мешать вам форматировать код. На самом деле важнее не то, какое форматирование вы используете, а тот факт, что вы используете его и последовательно используете во всем проекте.

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

Как реализовать стиль форматирования в проекте?

Итак, нам нужно отформатировать наш код, чтобы выиграть время, чтобы легче понять код, который мы читаем. И нам нужно быть последовательными, что означает, что у нас есть только один вид форматирования (один стандарт) по проекту.

Но как его обеспечить? Как быть уверенным, что код, написанный любым соавтором проекта, хорошо отформатирован?

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

Таким образом, вы выигрываете время на удобочитаемости, но теряете время на интеграцию и проверку нового кода. Не удачная сделка, не так ли? Так что, мы должны прекратить форматирование?

Нет, решение — автоматизация.

Автоматическое форматирование

Почему лучше иметь возможность автоматически форматировать код?

Во-первых, автоматизация форматирования кода избавит вас от необходимости просматривать код только для поиска ошибок форматирования. Таким образом, вы выигрываете некоторое время назад. ⏲💲

Более того, соавторы с меньшей вероятностью будут спорить и пытаться навязать другое форматирование, если все, что им нужно сделать, это запустить команду для форматирования своего кода в формат проекта. Таким образом, вы получаете больше времени назад. ⏲💲

И в качестве бонуса, даже если вы или другой разработчик сделаете ошибку форматирования, автоматическое форматирование исправит ее. И мы можем пойти дальше! Вы можете писать код, не заботясь о форматировании, просто запустите команду автоматического форматирования, и вуаля, ваш код отформатирован! Итак, еще немного времени в ваших руках. ⏲⏲⏲💲💲💲

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

Вывод

Если это недостаточно ясно, вам обязательно следует отформатировать код. Я говорю даже больше! Вам обязательно следует автоматически отформатировать свой код. Это поможет вам выиграть немного времени и избежать комментариев по поводу форматирования, а сосредоточиться только на содержании, цели на исходном коде.

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

А пока наслаждайтесь обучением и ростом.

Первоначально опубликовано на https://10xlearner.com 7 ноября 2019 г.