Не пишите код на 45-й строке

КДПВ

Это перевод статьи блоггера Brian McKenna. Разрешение на перевод получено.

Прямо сейчас в сообществе DynamoDB собираются мнения. Должны ли вы писать код на 45-й строке или нет. Я твёрдо убеждён, что 45-я строка должна быть оставлена пустой. И вот почему.

45-я строка ниже края экрана


По умолчанию высота терминала — 24 строки. Если писать код на 45-й строке, то программисты не сразу заметят его. Если оставить 45-ю строку пустой, то программист ничего не пропустит. Код чаще читается, чем пишется, поэтому убедитесь, что он виден.

45-я строка непрактична


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

Я обратился на IRC, и кто-то сказал мне, что я смотрел неправильные уроки, и они написали несколько упражнений на замену. Мне жаль, но вы не можете ожидать, что непритязательные программисты из другой отрасли будут тратить время, делая упражнения. Когда вы обнаруживаете баг на продакшене, вы не можете терять время на упражнения c 45-й строкой, особенно, когда вас вызвали в 3 часа утра.

45-я строка излишняя


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

Все должно быть сделано так просто, как это возможно, но не проще.

Не нужно удалять строку, просто оставьте её пустой.

Строки 1, 39 и 60 лучше


Я понимаю, что это субъективно, но синтаксис действительно имеет значение. Любой, кто обучал джуниора, знает, что строки 39 и 60 более интуитивны. Их использование занимает немного больше времени, чем написание кода на 1-й строке, но сейчас все хорошо знакомы с их использованием. Мы не должны навязывать существующие идиомы написания кода на 45-й строке, в то время, как в школах в основном учат использовать 1-ю строку.

Заключение


Некоторые из нас писали код без 45-й строки десятилетия. Мы создали десятки приложений, обслуживающих миллионы пользователей. Это надёжный и понятный метод программирования. Попытка быть умным, используя 45-ю строку, не помогает вашим пользователям, а просто тешит ваше самолюбие. Будьте добры к бедным админам, которые вынуждены посреди ночи поднимать ваш сайт и прыгать по 45-й строке в своих дебаггерах.

Нам не нужна 45-я строка.

Update


Пользователь Zverik пояснил в комментариях о чём данная статья:

Понимаю, что сатира, но на что — не очень, потому что не слежу за ruby-сообществами. Пошёл на reddit:

  • Первый довод основывается на ложном предположении, что все терминалы высотой 24 строки.
  • «Раз для меня это сложно, этого нужно избегать».
  • «Раз это не требуется, давайте и не делать» — если что-то можно не делать, это не значит, что нужно не делать.
  • Про доводы от «любого, кто тренировал новичка» и строки 1, 39: довод от авторитета, «если этого не знаешь, ты никто».
  • Эта статья и демонстрирует субъективные доводы, которые подаются как истина, и показывает, как далеко мы ушли от научности, с которой когда-то было связано программирование.

На сайте lobste.rs заметили, что это ответ на статью использование знака «больше» в программах. Который показывает, что уровень дискуссии о конвенциях в программировании всё ниже и ниже.

Данный перевод посвящается пользователю Хабрахабр divan0. Спасибо вам за статьи (а в особенности за ваши комментарии к ним) о языке Go.

КДПВ взята здесь.
Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

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

    +23
    Больше похоже на первоапрельский пост, на первый взгляд
      +1
      На второй взгляд тоже.
      У меня к примеру 26 строк на 1080p. (Menlo, 17, 1.7)
      +1
      Пытаюсь понять, на что пародия? По аргументации похожа на какую-то конкретную статью.
        +2
        Так автор явно написал, что пародия на статьи и комментарии divan0 про язык Go.
          +1
          А что не так со статьями и комментариями divan0 ?
            +5
            Скорее всего во всех статьях используется 45 строка и автор часто попадает на 45 комментарий :)
            0
            Так автор явно написал, что пародия на статьи и комментарии divan0 про язык Go.

            Нет, это комментарий переводчика. А на что является пародией оригинальный пост — не понятно. Видимо с Go как-то связано, хотя смущает эта DynamoDB))
            0
            В начале же есть ссылка на оригинал, клик
            +6
            В треш.
              +7
              А мне понравилось безотносительно того, что этот перевод пародирует.
              Видел компании, которые разрабатывали свои стандарты кода месяцами, тратя время на их разработку, модернизацию, приведение кода к стандарту и так далее. Причём некоторые правила были неформализуемыми для IDE — то есть, внедрить их можно было только руками.

              Бессмысленные правила, стандарты, соглашения, регламенты, "хороший стиль" — всё это убивает безумное количество человекочасов, и в большинстве случаев никоим образом не влияет на качество продукта. Большинство таких правил абсолютно субъективны, на что так же намекает статья.

              Вообще, обо всём этом уже было сказано у Джонатана Свифта касательно войны "остроконечников и тупоконечников". Но за последние несколько тысяч лет человеческая природа изменилась не так сильно, как кажется — и война бессмысленных вопросов всё ещё актуальна.
                –5
                Давно уже пора перестать писать программы буквами, это пережиток прошлого. Программы нужно собирать из схем, каталогов элементов, интерактивно конфигурируемых компонентов и т.д. Всё в облаке и коллаборативно, конечно, и через тачевый интерфейс. С автоматическим анализом противоречивости архитектуры, с эвристическими подсказками, с версионностью компонентов и ролями программистов. Некоторые алгоритмы обработки данных (сортировки/фильтры/поиски), конечно, могут описываться языковыми конструкциями, но для прикладного программиста должны быть просто элементами меню «Параметры контейнера данных».

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

                Промышленное визуальное программирование — неизбежное, хотя ещё и не наступившее будущее. Рано или поздно текстовые языки программирования вымрут (в прикладном программировании) как ассемблер или латынь, IMHO.
                  +13
                  Предлагаю вам начать с отказа от использования букв в комментариях. Тоже вчерашний день. Будущее за смайликами, эмодзи и reaction gif'ками.
                    –4
                    Вы передёргиваете. Если бы вы оставались в рамках моей метафоры, то предложили бы использовать телепатию и нейроинтерфейсы вместо текстового общения. И да, это тоже было бы предложением, которым, увы, нельзя воспользоваться прямо сейчас. Но мечтать о таком не вредно и даже полезно, на мой взгляд.
                      +3
                      Вы слишком серьезны. Ну а как бывший филолог, могу вам сказать, что у буквенной письменности всегда будет преимущество перед идеографической и иероглифической.

                      image
                        0
                        Я как шумер могу сказать вам, что у клинописи всегда будет преимущество перед буквенной письменностью. Почему обычно удобнее пользоваться картой, а не текстовым описанием карты? Почему инженеры пользуются чертежами, а не текстовыми описаниями? Возможно, вы слишком категоричны в оценках _практичной_ сводимости любого типа абстрактной информации к тексту.
                          +2
                          Большинство водителей используют совместно карту и голосовые подсказки навигатора (текст в устной форме) неспроста. Ну а насчет преимуществ той или иной формы, просто сравните: сколько людей пишут на латинице/кириллице, а сколько используют другие формы.
                            –1
                            Я как шумер вижу вокруг, что все пользуются клинописью. Действительно, других форм не наблюдается (почти). Не связано ли это с сопутствующими технологиями изготовления текстовых носителей и их заполнения? А теперь сравните клинописную палочку с тачевым планшетом. Не пора ли попробовать поискать новые формы?
                              0
                              (Или хотя бы допустить их возможность.)
                            0
                            image
                            У "идеографической и иероглифической" информации иногда есть преимущество, если все адресаты точно понимают смысл и имеют ту же не-текстовую информацию (типа эмоций). Но попробуйте иностранцу показать эту картинку.
                            Если информация из большего количества слов, чем два-три, то прочитать быстрее. Особенно поэтому я не люблю видеоуроки.
                            0
                            何?
                          0
                          Ну как сказать, возможность вставить картинку или диаграмму прямо в код в качестве комментария — это очень удобно. Особенно когда дело математики касается.
                          0
                          Реализуйте.
                          Возможно вы станете одним из отцов-основателей Нового Программирования ))
                          На самом деле о таком программировании многие мечтают, но когда дело касается практики, все равно все сводится к тому, что нужно щелкнуть на компоненте и написать какой-то код в окошке (и это в лучшем случае).
                            –2
                            Верно, пока это всего лишь мечты. Различные редакторы блоксхем уже были, были и RAD-средства типа Delphi или VВ, были и попытки заменить редактирование текста редактированием AST (с автоматическим конвертированием представления логики в несколько ЯП). Но до цельной и монолитной концепции пока дело не дошло, всё это было в большей степени пока лишь надстройкой над текстовым представлением.
                              +1
                              Именно основателем не станет, т.к. все вакантные места таких отцов уже разобраны :)
                              Например, давно есть NI LabVIEW. Совсем без букв, конечно, не обойтись, но для многих задач можно вообще ни строчки кода руками не написать.
                              0
                              Вы слишком категоричны. Я пятнадцать лет программирую на LabVIEW. Автоматизация производства и машинное зрение. Это язык визуальный, и для меня — основной язык разработки. Смею вас заверить — без букв там не обходится, и переменным надо давать имена и всё такое. При этом я владею также С, С++ и С#. Более того, начинать изучение программирования надо именно с текстового языка. Знаю инженеров (как LabVIEW, так и ПЛК), вообще не владеющих текстовыми языками — программистами их назвать не могу. Я не в в том смысле, что они "глупые" — совсем нет, но мыслительный процесс их несколько своеобразен. Особенно когда им таки приходется что-то сделать в текстовом виде, ну, скажем программируя промышленный робот. Программирование на классическом текстовом языке заставляет голову работать в правильном направлении. Не знаю почему так, но это так.
                                0
                                Да, моя утопическая фантазия об интерфейсе IDE в стиле голливудского «Особого мнения» действительно была слишком провокационной.
                                  0
                                  Фантазия отнюдь не утопическая, я тоже считаю, что за визуальным програмированием будущее, но это очень далёкое будущее. Тут много факторов — современные средства разработки ПО к этому не готовы, взаимодействие человека и компьютера не очень развито, попытки сделать реальный интерфейс в стиле "особого мнения" выглядят красиво, но на самом деле нефункциональны, огромное количество существующего текстового кода, отсутствие каких бы то ни было стандартов на визуальный язык, бешеная стоимость средств разработки (LabVIEW c парой пакетов и подпиской упирается в десятку тысяч и отнюдь не рублей) и т.д. Сами посмотрите — доля того же LabVIEW, если взять рейтинг Tiobe — 0,3%. Подождите лет этак сто, может сто пятьдесят — пара-тройка поколений программистов сменится и ситуация начнёт меняться. Я так думаю, переломный момент наступит тогда, когда сама IDE будет написана на графическом языке. Ну а пока что среда LabVIEW сама по себе написана на старом добром С++.
                                    –1
                                    Вы правы, нужно программировать на C++, а фантазировать только о выплате ипотеки. Я уже осознал свою непростительную дерзость.
                              +8
                              Понимаю, что сатира, но на что — не очень, потому что не слежу за ruby-сообществами. Пошёл на reddit:

                              • Первый довод основывается на ложном предположении, что все терминалы высотой 24 строки.
                              • «Раз для меня это сложно, этого нужно избегать».
                              • «Раз это не требуется, давайте и не делать» — если что-то можно не делать, это не значит, что нужно не делать.
                              • Про доводы от «любого, кто тренировал новичка» и строки 1, 39: довод от авторитета, «если этого не знаешь, ты никто».
                              • Эта статья и демонстрирует субъективные доводы, которые подаются как истина, и показывает, как далеко мы ушли от научности, с которой когда-то было связано программирование.

                              На сайте lobste.rs заметили, что это ответ на статью использование знака «больше» в программах. Который показывает, что уровень дискуссии о конвенциях в программировании всё ниже и ниже.
                                0
                                Шутка про то, что в новом Swift решили избавиться от тернарников инкремента и декремента и стандартного цикла for.
                                  0
                                  Благодарю вас за пояснения. Процитировал комментарий в статье.
                                  +5
                                  Не лучший выбор для песочницы, ИМХО.
                                    0
                                    Имхо — все сугубо индивидуально. Это равносильно тому, что сказать: не пишите код больше n-строк на файл, ибо его можно не заметить\надо перелистывать
                                      0
                                      А мне почему-то вспомнилось то, что есть на скриншоте: не пишите строки больше 80 символов (и красная черта).
                                      Тоже уже многие мониторы позволяют обходить эту особенность, но ведь ограничение рассчитано на небольшие мониторы и для того, чтобы меньше глаза "пригали" со строки на строку.
                                      Нравится, как в PSR-2 описаны рекомендации по длине строки: "желательно" не больше 80 символов.
                                        0
                                        45-я строка ниже края экрана

                                        Зависит от размера экрана и его ориентации же

                                          +1
                                          Насколько мне известно, нет языка программирования, действительно требующего располагать какой-либо код на 45-й строке.

                                          Более того, насколько мне известно, нет языка программирования, который требовал бы писать какой-либо код на какой-либо строке. Так что, товарищи, начинайте писать строки с 300-й. Так будет интереснее.
                                            0
                                            Был язык программирования, который заставлял даже вручную нумеровать эти строки. GOTO 10 (я начинал с десятой, закладывая риск в десять дополнительных строк).
                                              0
                                              … и нумеровал тоже через 10, чтобы потом если что можно было код вставить
                                                0
                                                так это же бейсик! Я тоже так делал. В 1995 году у меня был советский компьютер БК-0010-01 (на гиктаймсе), в нём при входе сразу включался интерпретатор бейсика (а ещё был ещё один язык Фокал, в котором тоже нужно было ставить номера строк). И там обычно строки нумеровались десятками — 10, 20, 30… Это нужно было как раз для того, чтобы добавить строки между уже добавленными строками.
                                                  +1
                                                  В "хороших" Бейсиках была команда RENUM.
                                                    0
                                                    Либо у меня был плохой, либо просто некому было о ней рассказать.
                                              +2
                                              Чем-то напомнило О вреде огурцов.

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

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