Правая граница в исходном тексте

При офомлении исходного текста все мы пользуемся каким либо Code Convention. Хорошо, когда внутри компании есть документ, который описывает эти соглашения. Если нет, то приходится пользоваться каким-то общеизвестным, который нам кажется стандартным. Хотя, конечно, понятие его стандартности весьма относительно. Лучше все таки иметь такой документ внутри компании, что бы не было разнологласий в команде.

Один из вопросов, который возникает при формировании такого документа — правая граница в исходном тексте. Раньше было принято использовать правую границу 80 (а то и 76) символов. Но сейчас мониторы широкие. Может быть можно и не ограничивать? Или все таки надо ограничивать? Вот, например, и совсем недавно, в этой статье данный вопрос вызвал довольно большую полемику. Под катом мое видение этого вопроса + опрос.

Почему сложилось такое ограничение — 80 символов? Немного историю. Вы, конечно, быстро вспомните, что такую ширину имели старые мониторы в текстовм режиме. Это ограничение было особенно важно когда мониторы (вместе с видеосистемой) еще не имели графического режима. И поэтому было принято стараться вмещать текст программы в 80, а еще лучше в 78 или даже 76 символов. Меньше 80 было принято использовать потому, что на некоторых не очень качественных мониторах правая и левая сторона или сильно искажались или вообще скрывались за кожух. Мне попадалось много мониторов, у которых терялось слева и справа примерно по половине знакоместа.

Помимо мониторов такую ширину имели принтеры. Конечно, были и широкие принтеры. Но наиболее доступные принтеры расчитанные на бумагу формата А4 или рулон такой же (210мм) ширины аккуратно пропечатывали на бумаге те же 80 символов.

Более того, на перфокарте тоже вмещалось 80 символов.

То есть, 80 символов ширины строки был, де-факто, индустриальный стандарт, который был введен, по моему предположению, компанией IBM.

С историей разобрались.

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

Может возникнуть вопрос: а в чем, собсвенно, проблема, что исходный текст выходит за границу? Может быть и пусть? Компилятору не очень важно какова там длина строки. А даже если у нас экран все еще имеет ширину 80 символов, и нам надо в IDE посмотреть, что там за правой границей экрана, то можно встать курсором на эту строку и перейти в конец. Может это выход?

На самом деле — нет. Это не выход. Мы пишем исходный текст, что бы его читали люди, а не только компилятор :). Если программист, который читает исходный текст чего-то не видит сразу, одним взглядом, то с высокой вероятностью он что-то упустит и не поймет. Или потратит время.

Но почему на современных мониторах не уйти от этого стандарта? Действительно значимость 80 символов стала снижаться по мере перехода на графические экраны с относительно высоким разрешением. Если при разрешении 640х480 VGA адаптера вместить на экран больше тех же самых 80 символов (8 пикселей на ширину каждого символа) было сложно (хотя я видел относительно неплохо читаемые шрифты имеющие 5 и 6 пикселей на каждый символ по ширине). То уже при разрешении 1024х768 можно было или повысить качество отрисовки символов или увеличить их количество на строку. Ну или просто добавить слева и справа от исходного текста какие-то дополнительные функции — дерево проекта, чат с другим разработчиком и так далее.

Есть еще вариант — не переносить строку самостоятельно, а оставить эту работу на IDE при отображении автоматически. То есть, реально это одна длиная строка, но в IDE она отображается с переносом. Может быть это выход из положения? В принцие, это уже менее плохо… Почему-то такой вариант оказался у знакомых мне iOS разработчиков. Наверное, потому, что с в связи с собенностями языка Objective C перенос на другую строку не всегда очевиден. То есть, не всегда ясно и понятно что именно и где именно нужно переносить. Ну и, наверное, поэтому Apple по умолчанию в своей IDE (которая называется Xcode) сделали такую опцию включенной по умолчанию.

Но опять же. Мы же пишем исходный текст для людей. Не так ли? А при таком автоматическом режиме переноса структура функции, может быть потеряна, а следовательно, логику будет понять сложнее. Поэтому, это тоже плохой вариант.

Третий вариант. При современных 1920 и более пикселей ширины качественно отобразить большое количество символов не проблема. Может быть оставим правую границу как таковую, но при этом, увеличим ее со старых 80-ти до 160? или хотя бы 120 символов?

Ну этот вариант еще лучше, чем предыдущий. И все же. Конечно, мониторы сейчас широкие. При соотношении сторон 9:16 или 10х16 и имея разрешение по широкой стороне, скажем, 1920 или 2560 пикселей текста может вместиться много. Причем, с качественным рендером шрифтов.

И все было бы хорошо… Ну а если Вам придется объединять (мёржить) несколько веток исходного текста? Например, как будет смотреться трехточечный мерж?

Например, вот скриншоты KDiff3. Особенно вот этот:

Как теперь будут выглядеть три копии Вашего исходного текста в 120 символов шириной каждая на Вашем мониторе с всего 1920 пикселей шириной? Вам придется или жертвовать качеством рендера шрифтов, то есть, уменьшать размер и напрягать глаза. Или терять часть логики, которая будет скрываться за правой границей. Второй вариант вообще не приемлем! Так как потребность в трехточечном мерже возникла в результате конфликта. И мне (или Вам), в процессе мержа нужно в точности понять логику, которую реализовал другой разработчик в левой версии исходного текста, относительно базы (по центру) и правой версии исходного текста относительно базы. Нужно видеть всю логику!

При ширине экрана в 1920 пикселей я получаю 80 символов по 8 пикселей на каждый символ по ширине на все 3 версии исходного текста. И это еще не считая накладных расходов на отображении номеров строк, границ и так далее.

Поэтому, я за границу в 76 символов!

Ну ладно, 3-х точечный мёрж случается не каждый день. Пусть граница будет в 100 символов. Но не более 🙂