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

    При офомлении исходного текста все мы пользуемся каким либо 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. Особенно вот этот:

    image

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

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

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

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

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    А Вы что думаете по поводу правой границы?

    Поделиться публикацией

    Похожие публикации

    Комментарии 84

      +6
      Ох, что тут сейчас будет…
        +5
        Дык пятница :) Можно и похоливарить.
        +12
        разрешение монитора тут не причём, исходный код должен быть простым и читаемым

          +1
          Соглашаюсь с предыдущим комментатором. Чем короче строки, тем легче он читается. А читабельность кода — один из залогов его надежности.
            0
            Именно так. Исходный текст должен быть простым и читаемым. И шрифт, а в конечном счете и разрешение экрана здесь играют не последюю роль. Ниже есть комментарий, про, примерно половину экрана в IDE, я с этим постулатом согласен.

            Я здесь говорю про ту проблему, которая для многих, на мой взгляд не очевидна. Исходный текст должен оставаться читаемым не только в IDE, но и при мёрже, где текста должно вмещаться на экран в два или в три раза больше, и он должен, по прежнему, оставаться читемым.
              0
              Когда какая-нибудь функция библиотеки или API (да хотя бы в том же WinAPI), которые не можешь изменять, десяток параметров, то в одну 80-симаольную строку все-равно все не влезет.
                +3
                Каждый параметр в отдельную строку повысит читаемость.
                  0
                  Обычно именно так и поступаю.
                    0
                    С чего это? Наоборот понижает. Выделение строкой — это повышение внимание.
                –1
                Даже не подозревал что существует такая граница. Сам стараюсь писать, чтобы ширина текста была немного больше половины монитора — так читать удобнее.
                  +1
                  главное, чтобы при совместной работе с другими программистами, не приходилось ходить к ним со своим монитором. а то у нас тут некоторые на 30" работают.
                  +6
                  Для действительного удобного чтения и восприятия информации строка текста должна охватываться одним взглядом, без поворота головы, это значительно упрощает чтение, поэтому я за 80-120.
                    +2
                    Верно. В книгах стараются вместить в строку примерно 60 символов, в журнальных и газетных статьях — и того меньше.
                    0
                    Поставил в редакторе границу в 120 для работы существующим проектом, но стараюсь разбивать строку пораньше.

                    Психологически дискомфорт в том, что как 120, так и 100 — числа, взятые с потолка и ничем логически не обоснованные.
                    • НЛО прилетело и опубликовало эту надпись здесь
                      +1
                      Вставлю свои 5 копеек, раз уж выбрал вариант «Напишу свой вариант».
                      Писать время от времени приходится на массе разных ЯП, но наиболее часто на PHP (PSR2 говорит о 80-120 символах) и Python (PEP8 — 79 символов). Сам обычно придерживаюсь 50-70 символов, со строгим ограничением в 120 (для комментариев, или когда разбиение на несколько строк значительно ухудшает восприятие).
                      Но если отбросить все эти стандарты и привычки, то мне кажется, что компактный по ширине код воспринимается легче, т.к. глаза меньше бегают по горизонтали.
                        +2
                        Есть ещё момент правки файлов через терминал или в виртуальной машине. Конечно современные терминалы позволяют расширить обзорную часть, но если открыто несколько окон, удобнее их держать в компактном виде. Из этого вытекает одно из правил, который я стараюсь блюсти — не писать код больше одного экрана.
                        • НЛО прилетело и опубликовало эту надпись здесь
                            +1
                            В идеале конечно хотелось бы. «Работай!». И все как по маслу.
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • НЛО прилетело и опубликовало эту надпись здесь
                            • НЛО прилетело и опубликовало эту надпись здесь
                              • НЛО прилетело и опубликовало эту надпись здесь
                              +16
                              Просто оставлю это здесь.

                                0
                                Думаю, играло роль и то, что некоторые колонки могли быть заняты. К примеру, в борландовых текстовых IDE была рамочка окошек, отъедавшая два знакоместа.
                                +1
                                Я использую границу 80 символов. В подавляющем большинстве случаев удаётся укладывать строки в этот предел.
                                Конечно, нужно руководствоваться здравым смыслом, и иногда можно выйти за эти границы на несколько символов, так как строка такой длины будет более читаемой, чем разбитая.
                                  +5
                                  Если вы пишете на современном языке и вам надо написать очень длинную строчку (или не длинную, но с большим отступом слева) — вы, скорее всего, что-то делаете не так.

                                  Но и ограничение в 80 символов — просто смешно, половина монитора пустует.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      0
                                      Это да, но есть же средства для борьбы с callback-hell'ом.
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                        +2
                                        Ну, например, когда на JS пишешь для Node.js там периодически бывают оооочень глубокие отступы

                                        Не бывают. Ну если, конечно, вы не забываете о нормальной архитектуре, разбиваете код на подпрограммы, а не пишете лапшу в стиле Джуниоров.
                                        Вложеность в 4 таба — это уже редкость.
                                          0
                                          Мне тут заявили, что лучше 6 табов и 5 экранов текста, чем 5 функций по 2 таба и одному экрану
                                            +8
                                            Ударьте этого человека книгой о Рефакторинге.
                                            А то писать быдлокод все гаразд, а как его потом поддерживать — никто не задумывается.
                                              0
                                              Ну иногда он даже разумно говорит… И даже с ходу сказать не можешь ничего, хотя знаешь, что так нельзя
                                              0
                                              Лучше одна функция на 500 экранов в 1 строку.
                                              Компактно, переносимо, не раздражает глаз.
                                              А если при этом чешутся руки, то лучше почесать и выключить монитор
                                        +3
                                        Стараюсь писать код компактно, но без конкретного ограничения на длину строки. Там, где это уместно, строка получается длиннее 80-ти символов.

                                        Иногда без длинной строки просто не обойтись. Например, на языке SASS иначе просто не написать. Получается некрасиво (пример), но что поделать… IDE (JetBrains IDEA) выручает, позволяя включать line wraps индивидуально для отдельных файлов.

                                        Текст (всякие README.md, пример: рендер, исходник) никогда не переношу. Дело в том, что если делать переносы, то дописывание текста превращается в мучение. Добавил пару строк, сиди, исправляй переносы для всего абзаца.
                                          +1
                                          Дело в том, что если делать переносы, то дописывание текста превращается в мучение. Добавил пару строк, сиди, исправляй переносы для всего абзаца.
                                          Очередной пример превосходства Vim над другими жалкими редакторами. ;)
                                            0
                                            А зачем тогда переносить?
                                              0
                                              В смысле зачем? Я имел в виду, что в Vim есть стандартная команда gq, которая переразбивает выделенный текст так, чтобы он вместился в заданное количество символов по ширине.
                                                0
                                                В Emacs тоже есть M-q. Я все текстовые документы и комментарии в коде через него прогоняю.
                                                  0
                                                  но зачем это для текста?
                                              +3
                                              Горячо плюсую. Я в восторге, как Vim позволяет перемещаться по коду, не меняя положения правой руки.

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

                                              Почему в Vim есть навигация по коду при помощи клавиш-букв? Потому что в 70-е годы на клавиатурах не было клавиш-стрелок.
                                              Почему Vim автоматически корректирует переносы? Потому что в 70-е годы оборудование и ПО не было совместимо с длинными строками.

                                              Но мы-то живем в будущем, и эти воробьи давно вымерли, а вместе с ними пропала и потребность в гаубице для стрельбы по ним.
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                              +4
                                              Условия можно разбить на несколько булевских переменных. Так даже проще разбираться.
                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                +12
                                                > Исходный код … не «читают»

                                                Вон из профессии!
                                                  0
                                                  его не «читают»
                                                  Некоторые считают иначе: Seven Pillars of Pretty Code
                                                  К сожалению, сайт perforce переделали, и оригинальная ссылка больше не доступна.
                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                  0
                                                  80, но не жёстко. Если по читаемости получается лучше не переносить (как правило, в сложных выражениях), не переношу.
                                                  Жёсткая — где-то 100 или 120.
                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                      0
                                                      Emacs, C-x 3 на 22'' мониторе — в самый раз для 80 символов.
                                                        +2
                                                        Слишком маленькие строчки — плохо.

                                                        У нас есть человек, который настаивает на следующем:

                                                        fuc(a,
                                                        b,
                                                        c,
                                                        d,
                                                        e,
                                                        f)

                                                        И получается такая портянка… Зато мерджится хорошо, особенно если программа не показывает изменения в строке.
                                                          0
                                                          Ужас! А какой язык, если не секрет?
                                                            0
                                                            python
                                                            Правда конечно переменные не однобуквенные. Но это ад. Было 10 строчек, а теперь 2 экрана.
                                                              0
                                                              Гм, а почему бы не

                                                              tmp_x = fuc(a, b, c, d, e, f)
                                                              
                                                              # используем tmp_x 
                                                              

                                                              ?
                                                                0
                                                                Если было

                                                                f(
                                                                a,
                                                                b,
                                                                c,
                                                                )

                                                                а стало

                                                                f(
                                                                a,
                                                                b,
                                                                c,
                                                                d,
                                                                )

                                                                это будет добавление строки, а не изменение строки. Типа мерджить проще.
                                                                  +1
                                                                  Но читать-то код от этого легче не станет? По-моему это всё-таки перегиб — писать код исходя из того, «чтобы было легче 'мерджить'».
                                                                    0
                                                                    Это читать просто невозможно. Если еще и запятые писать перед, чтоб легче удалять. Или

                                                                    if( a == b ) {
                                                                    }
                                                                    else {
                                                                    }

                                                                    if( a== b )
                                                                    stm;
                                                                    else stm2;

                                                                    чтоб else одной строкой можно было удалить
                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                              0
                                                              В питоне можно и так написать

                                                              func(
                                                              a,
                                                              b,
                                                              c,
                                                              d,
                                                              )

                                                              Точнее он так и пишет
                                                                0
                                                                да да. Именно, запятые впереди!
                                                                Примерно об этом хотел написать следующую статью.
                                                                Вопрос, конечно, не менее холиварный, чем 80. Но эта точка зрения имеет под собой весьма вескую базу.
                                                              +2
                                                              Если давать осмысленные имена переменным и правильно расставлять отступы, то 80 символов порой не хватает. У меня как то исторически сложилась граница в 100 символов. Более длинная — уже не всегда охватишь взглядом. Ну и конечно, граница не жесткая. Если что то не помещается на пару символов — я прощаю. Форматирование по ширине автоматическое.
                                                                +1
                                                                80 — наше все. Как кто-то в свое время отметил, «Вертикальный лайаут кода стимулирует короткие фразы на нем, заставляет разработчика писать не вширь, а вглубь».
                                                                  0
                                                                  ага. и использовать односложные переменные.
                                                                    +1
                                                                    Но имена типа «ValueOfSomeParameterThatRequiredInSomeCase» тоже не лучшая практика.
                                                                  +4
                                                                  Стараюсь писать код как можно короче (<80), но если ради читаемости или удобства восприятия необходимо больше пространства прибегаю к этому.

                                                                  Из своего опыта я сталкивался с потребностью в длинных строках когда:
                                                                  1. Много параметров у метода — ртешение: использовать либо структуру для передачи параметров, либо метод выполняет слишком много действий и в итоге требует рефакторинга.
                                                                  2. Условие из слишком много условий — решение: зарефакторить таким образом чтобы большая часть условий вычислялись заранее и присваивались коротким но осмысленным переменным, либо вынос условий в методы (часто не один метод).
                                                                  3. Выражение по вычислению чего-либо слишком длинное. решение: разбить на куски и по отдельности вычислить либо вынести кое-что в методы.
                                                                  4. Вырежение-вызов метода с не большим количеством параметров, но содержащий длинные идентификаторы (10+ символов). В принципе такое можно отрефакторить но не всегда. Вот такие случаи:
                                                                  — Укоротить идентификаторы невозможно, потому что читабильность уменьшится.
                                                                  — Вынести расчет параметров в отдельности невозможно потому что они и так записаны как идентификатор на переменную.
                                                                  В итоге подобная ситуция может вылится в 100-120 символов. Что никогда не была проблемой для меня и моих коллег.

                                                                  В итоге наличие длинных строк ситуция оооочень редкая, но не критичная с моей точки зрения.
                                                                  ЗЫ: Пишу на Java.
                                                                    0
                                                                    Границу повесил на 120, стараюсь не вылезать, но не фанатично (ага, в xml совсем не вылезать...). Проблема с мёржем/дифом отлично решается двумя мониторами.

                                                                    PS мне читать узкие колонки гораздо сложнее, чем широкие строки. И ридер и планшет при чтении я переворачиваю в горизонтальное разрешение.
                                                                      +3
                                                                      Как пользователь спектрума настаиваю на границе в 64 символа. Иначе не влазит в строку на 50см телевизоре (разрешение 256х192).

                                                                      Как пользователь мониторов с разрешением 2560х1440 воспринимаю ваши слёзы по поводу «не влазит на 1920» как ретроградство.
                                                                        0
                                                                        Классический синклер, если мне не изменяет мой склероз, имел 32*24 символов, а Радио 86РК как раз имел 64*25
                                                                          0
                                                                          Да, туплю с делением. 256/8=32.
                                                                        +1
                                                                        Как теперь будут выглядеть три копии Вашего исходного текста в 120 символов шириной каждая на Вашем мониторе с всего 1920 пикселей шириной?

                                                                        У меня два монитора. 3-х точечный мердж использую редко, а два монитора идеальны для обычного.
                                                                        Код пишу так, чтобы строчка влезала на экран монитора. Становится удобно писать громоздкие языковые конструкции, давать длинные и ясные имена переменным и тп.
                                                                        Посмотрел — почти все строки вмещаются в 160 символов.
                                                                          +1
                                                                          Не понимаю, какой смысл открывать текстовый редактор на весь экран — всё равно большинство строк короткие. Лучше открыть IDE на полэкрана или разбить редактор на два файла но горизонтали.

                                                                          Так что граница 80-символов ещё актуальна.
                                                                            +1
                                                                            Пишу на xslt, сделал табы в 2 пробела, но один фиг некоторые конструкции в длину могут превышать 200 знаков. Не вижу в этом проблемы в силу специфики самого языка.
                                                                              +3
                                                                              Да, язык говно, с этим спорить сложно
                                                                                +1
                                                                                По сравнению с возможными альтерантивами в моей ситуации — он великолепен и полностью решает все возложенные на него задачи. Многобукаф — не самый отвратный вариант.
                                                                              +1
                                                                              Люблю классику.
                                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                                    +1
                                                                                    Раз уж Вы сами упомянули Kdiff3, то можете поглядеть в сторону пункта Toggle Split Orientation в меню Window. Иногда очень пригождается.
                                                                                      0
                                                                                      Да, я его в горизонтальном сплите всегда использую.
                                                                                      +3
                                                                                      Одна из самых смешных вещей, которые я встречал в чужом коде — это костыль, спрятанный табами куда-то за границу >200 символа. Вот идешь по коду в отладке, прыгаешь со строки на строку, а происходит черти-что. Я раз 10 проходил это место в отладчике, пока заметил горизонтальный скрол.
                                                                                        0
                                                                                        На GitHub без горизонтальной прокрутки влезает 124 символа, в диффе 104, так что 100 в самый раз.
                                                                                          0
                                                                                          На каком разрешении?

                                                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                      Самое читаемое