Выбор оптимального ограничения длины строки в коде

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

Также помимо 80 символов, во многих проектах и руководствах по стилю, можно встретить ограничения в 100 и в 120 символов, что явно дает понять, что не во всех случаях 80 символов является оптимальным ограничением.

Проблемы определенных ограничений длины строки в коде

80 символов - наиболее популярное ограничение и поэтому именно с этого числа и стоит начинать рассмотрение при принятий правил ограничения строк в коде проекта.

Актуальность ограничения в 80 символов

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

• позволяет свободно использовать в работе увеличенный шрифт для людей, с плохим зрением, а таких людей в IT много.
• при сравнении кода (diff и пр.) хорошо подходит при одновременном отображений в ширину 2-3 листингов кода.
• часто является удобным при работе с кодом на небольшом по ширине экране, например на широкоформатных мониторах в "портретном режиме" (под углом 90°), небольшие ноутбуки, windows-планшеты и пр.

Недостатки ограничения в 80 символов

Ограничение в 80 символов также имеет и свои недостатки. Например, в языках, использующих декларативный стиль (привет XML, HTML и пр.), ограничение в 80 символов, нередко может приводить к ужасному виду. В том же HTML может быть большая глубина вложенности тегов и с учетом отступа каждого тега, суммарный отступ наиболее вложенных тегов может быть настолько большим, что тег (с его атрибутами) и его содержимое будет сильно ужиматься по горизонтали и значительно растягиваться вертикально из-за большого количества переносов строк.

Конечно, большой HTML лучше по возможности разбивать на небольшие части (например, с помощью шаблонизаторов), чтобы избегать больших вложенностей, но даже при этом такой ограниченный в 80 символов код нередко выглядит хуже и поэтому для кода в декларативном программировании вполне может быть оправданным расширение ограничения длины строки до 120 символов.

Так же и в достаточно "многословных" императивных языках (например, TypeScript), ограничение в 80 символов может вынуждать слишком сжато писать код и использовать чрезмерно короткие и менее очевидные имена переменных. Для таких случаев, вполне оптимальным компромиссом может являться ограничение длины в 100 символов.

Кстати, не так давно Линус Торвальдс очень интересно высказался о проблемности строгого ограничения в 80 символов при разработке ядра Linux и с версии ядра 5.7 разработчики убрали это строгое ограничение, сделав его просто предпочтительным.

Читаемость кода как главный фактор при выборе ограничения длины

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

Значимость автоматического форматирования кода привыборе

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

«Все, что может быть автоматизировано, должно быть автоматизировано»

Автоматизация форматирования кода избавляет от долгих дискуссии на тему, какую принять длину строки, выбрать для отступов табы или пробелы и пр. нюансы оформления кода.

Существует множество инструментов автоматического форматирования кода под различные языки, такие как Prettier (JS, TS и куча других), gofmt (Golang) и пр. Соответственно, изначально принимаете в команде какой-то соглашение по стилю написания кода, затем настраиваете под это соглашение автоматическое форматирование, а дальше просто копируете из проекта в проект эти настройки.

Для поддержки кодовой базы в согласованном состоянии (независимо от используемого IDE и окружения), автоматизацию и проверку кода можно задать в Git хуки или инструментарии CI/CD. В таком случае в репозитории будет отправляться автоматически отформатированный код.

Стоит также отметить, что инструменты автоматического форматирования не избавляют от необходимости применения линтеров, потому что отвечают только за форматирование и никак не могут уберечь от использования нежелательного кода или API.

Кстати, для тех кто использует в работе TypeScript, вы можете обратить внимание на проект GTS, который представляет собой набор из заранее настроенного линтера (eslint), инструментов форматирования кода (Prettier) и готового соглашения по стилю кода (Google TypeScript Style Guide + версия моего перевода на русский язык).

Заключение

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

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