Это перевод статьи блоггера 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.
КДПВ взята здесь.
Комментарии (42)
Cyrus
25.02.2016 13:52+1Пытаюсь понять, на что пародия? По аргументации похожа на какую-то конкретную статью.
terryP
25.02.2016 13:55+2Так автор явно написал, что пародия на статьи и комментарии divan0 про язык Go.
NeoCode
25.02.2016 13:57+1А что не так со статьями и комментариями divan0 ?
UnixMaster
25.02.2016 14:01+5Скорее всего во всех статьях используется 45 строка и автор часто попадает на 45 комментарий :)
admax
25.02.2016 14:24Так автор явно написал, что пародия на статьи и комментарии divan0 про язык Go.
Нет, это комментарий переводчика. А на что является пародией оригинальный пост — не понятно. Видимо с Go как-то связано, хотя смущает эта DynamoDB))
jehy
25.02.2016 14:44+7А мне понравилось безотносительно того, что этот перевод пародирует.
Видел компании, которые разрабатывали свои стандарты кода месяцами, тратя время на их разработку, модернизацию, приведение кода к стандарту и так далее. Причём некоторые правила были неформализуемыми для IDE — то есть, внедрить их можно было только руками.
Бессмысленные правила, стандарты, соглашения, регламенты, "хороший стиль" — всё это убивает безумное количество человекочасов, и в большинстве случаев никоим образом не влияет на качество продукта. Большинство таких правил абсолютно субъективны, на что так же намекает статья.
Вообще, обо всём этом уже было сказано у Джонатана Свифта касательно войны "остроконечников и тупоконечников". Но за последние несколько тысяч лет человеческая природа изменилась не так сильно, как кажется — и война бессмысленных вопросов всё ещё актуальна.
napa3um
25.02.2016 14:54-5Давно уже пора перестать писать программы буквами, это пережиток прошлого. Программы нужно собирать из схем, каталогов элементов, интерактивно конфигурируемых компонентов и т.д. Всё в облаке и коллаборативно, конечно, и через тачевый интерфейс. С автоматическим анализом противоречивости архитектуры, с эвристическими подсказками, с версионностью компонентов и ролями программистов. Некоторые алгоритмы обработки данных (сортировки/фильтры/поиски), конечно, могут описываться языковыми конструкциями, но для прикладного программиста должны быть просто элементами меню «Параметры контейнера данных».
Современные программисты, кажется, погрязли в спорах об отступах, о кэмэлкейсах, о скобках, отодвинув алгоритмы и архитектуру на второй план. Слишком много усилий прикладывается к тому, чтобы в виде исходного текста описать всего лишь какую-нибудь одну стрелку, соединяющую два компонента, или какой другой атомарный аспект умозрительной схемы приложения в голове программиста. Было бы гораздо эффективнее этой стрелкой оперировать непосредственно, без конвертирования в текст туда-сюда и контроля того, как поняли этот текст остальные. Зачастую на выдумывание имени промежуточной переменной тратится изрядное количество усилий, когда она является всего лишь способом «тыкнуть пальцем сюда и сюда и сказать, что это одно и то же».
Промышленное визуальное программирование — неизбежное, хотя ещё и не наступившее будущее. Рано или поздно текстовые языки программирования вымрут (в прикладном программировании) как ассемблер или латынь, IMHO.stardust_kid
25.02.2016 15:38+13Предлагаю вам начать с отказа от использования букв в комментариях. Тоже вчерашний день. Будущее за смайликами, эмодзи и reaction gif'ками.
napa3um
25.02.2016 15:57-4Вы передёргиваете. Если бы вы оставались в рамках моей метафоры, то предложили бы использовать телепатию и нейроинтерфейсы вместо текстового общения. И да, это тоже было бы предложением, которым, увы, нельзя воспользоваться прямо сейчас. Но мечтать о таком не вредно и даже полезно, на мой взгляд.
stardust_kid
25.02.2016 16:09+3Вы слишком серьезны. Ну а как бывший филолог, могу вам сказать, что у буквенной письменности всегда будет преимущество перед идеографической и иероглифической.
napa3um
25.02.2016 16:13Я как шумер могу сказать вам, что у клинописи всегда будет преимущество перед буквенной письменностью. Почему обычно удобнее пользоваться картой, а не текстовым описанием карты? Почему инженеры пользуются чертежами, а не текстовыми описаниями? Возможно, вы слишком категоричны в оценках _практичной_ сводимости любого типа абстрактной информации к тексту.
stardust_kid
25.02.2016 16:18+2Большинство водителей используют совместно карту и голосовые подсказки навигатора (текст в устной форме) неспроста. Ну а насчет преимуществ той или иной формы, просто сравните: сколько людей пишут на латинице/кириллице, а сколько используют другие формы.
napa3um
25.02.2016 16:22-1Я как шумер вижу вокруг, что все пользуются клинописью. Действительно, других форм не наблюдается (почти). Не связано ли это с сопутствующими технологиями изготовления текстовых носителей и их заполнения? А теперь сравните клинописную палочку с тачевым планшетом. Не пора ли попробовать поискать новые формы?
lexxpavlov
26.02.2016 14:02
У "идеографической и иероглифической" информации иногда есть преимущество, если все адресаты точно понимают смысл и имеют ту же не-текстовую информацию (типа эмоций). Но попробуйте иностранцу показать эту картинку.
Если информация из большего количества слов, чем два-три, то прочитать быстрее. Особенно поэтому я не люблю видеоуроки.
AndreyDmitriev
26.02.2016 16:17Ну как сказать, возможность вставить картинку или диаграмму прямо в код в качестве комментария — это очень удобно. Особенно когда дело математики касается.
NeoCode
25.02.2016 15:44Реализуйте.
Возможно вы станете одним из отцов-основателей Нового Программирования ))
На самом деле о таком программировании многие мечтают, но когда дело касается практики, все равно все сводится к тому, что нужно щелкнуть на компоненте и написать какой-то код в окошке (и это в лучшем случае).napa3um
25.02.2016 15:52-2Верно, пока это всего лишь мечты. Различные редакторы блоксхем уже были, были и RAD-средства типа Delphi или VВ, были и попытки заменить редактирование текста редактированием AST (с автоматическим конвертированием представления логики в несколько ЯП). Но до цельной и монолитной концепции пока дело не дошло, всё это было в большей степени пока лишь надстройкой над текстовым представлением.
iUser
26.02.2016 05:05+1Именно основателем не станет, т.к. все вакантные места таких отцов уже разобраны :)
Например, давно есть NI LabVIEW. Совсем без букв, конечно, не обойтись, но для многих задач можно вообще ни строчки кода руками не написать.
AndreyDmitriev
26.02.2016 16:10Вы слишком категоричны. Я пятнадцать лет программирую на LabVIEW. Автоматизация производства и машинное зрение. Это язык визуальный, и для меня — основной язык разработки. Смею вас заверить — без букв там не обходится, и переменным надо давать имена и всё такое. При этом я владею также С, С++ и С#. Более того, начинать изучение программирования надо именно с текстового языка. Знаю инженеров (как LabVIEW, так и ПЛК), вообще не владеющих текстовыми языками — программистами их назвать не могу. Я не в в том смысле, что они "глупые" — совсем нет, но мыслительный процесс их несколько своеобразен. Особенно когда им таки приходется что-то сделать в текстовом виде, ну, скажем программируя промышленный робот. Программирование на классическом текстовом языке заставляет голову работать в правильном направлении. Не знаю почему так, но это так.
napa3um
26.02.2016 20:53Да, моя утопическая фантазия об интерфейсе IDE в стиле голливудского «Особого мнения» действительно была слишком провокационной.
AndreyDmitriev
29.02.2016 09:17Фантазия отнюдь не утопическая, я тоже считаю, что за визуальным програмированием будущее, но это очень далёкое будущее. Тут много факторов — современные средства разработки ПО к этому не готовы, взаимодействие человека и компьютера не очень развито, попытки сделать реальный интерфейс в стиле "особого мнения" выглядят красиво, но на самом деле нефункциональны, огромное количество существующего текстового кода, отсутствие каких бы то ни было стандартов на визуальный язык, бешеная стоимость средств разработки (LabVIEW c парой пакетов и подпиской упирается в десятку тысяч и отнюдь не рублей) и т.д. Сами посмотрите — доля того же LabVIEW, если взять рейтинг Tiobe — 0,3%. Подождите лет этак сто, может сто пятьдесят — пара-тройка поколений программистов сменится и ситуация начнёт меняться. Я так думаю, переломный момент наступит тогда, когда сама IDE будет написана на графическом языке. Ну а пока что среда LabVIEW сама по себе написана на старом добром С++.
napa3um
29.02.2016 09:24-1Вы правы, нужно программировать на C++, а фантазировать только о выплате ипотеки. Я уже осознал свою непростительную дерзость.
Zverik
25.02.2016 14:55+8Понимаю, что сатира, но на что — не очень, потому что не слежу за ruby-сообществами. Пошёл на reddit:
- Первый довод основывается на ложном предположении, что все терминалы высотой 24 строки.
- «Раз для меня это сложно, этого нужно избегать».
- «Раз это не требуется, давайте и не делать» — если что-то можно не делать, это не значит, что нужно не делать.
- Про доводы от «любого, кто тренировал новичка» и строки 1, 39: довод от авторитета, «если этого не знаешь, ты никто».
- Эта статья и демонстрирует субъективные доводы, которые подаются как истина, и показывает, как далеко мы ушли от научности, с которой когда-то было связано программирование.
На сайте lobste.rs заметили, что это ответ на статью использование знака «больше» в программах. Который показывает, что уровень дискуссии о конвенциях в программировании всё ниже и ниже.msnre
25.02.2016 15:18Шутка про то, что в новом Swift решили избавиться от тернарников инкремента и декремента и стандартного цикла for.
Zzepish
25.02.2016 18:52Имхо — все сугубо индивидуально. Это равносильно тому, что сказать: не пишите код больше n-строк на файл, ибо его можно не заметить\надо перелистывать
Akdmeh
25.02.2016 22:23А мне почему-то вспомнилось то, что есть на скриншоте: не пишите строки больше 80 символов (и красная черта).
Тоже уже многие мониторы позволяют обходить эту особенность, но ведь ограничение рассчитано на небольшие мониторы и для того, чтобы меньше глаза "пригали" со строки на строку.
Нравится, как в PSR-2 описаны рекомендации по длине строки: "желательно" не больше 80 символов.
lain8dono
26.02.2016 01:2645-я строка ниже края экрана
Зависит от размера экрана и его ориентации же
AdmAlexus
26.02.2016 06:13+1Насколько мне известно, нет языка программирования, действительно требующего располагать какой-либо код на 45-й строке.
Более того, насколько мне известно, нет языка программирования, который требовал бы писать какой-либо код на какой-либо строке. Так что, товарищи, начинайте писать строки с 300-й. Так будет интереснее.napa3um
26.02.2016 22:09Был язык программирования, который заставлял даже вручную нумеровать эти строки. GOTO 10 (я начинал с десятой, закладывая риск в десять дополнительных строк).
Randl
27.02.2016 03:03… и нумеровал тоже через 10, чтобы потом если что можно было код вставить
lexxpavlov
27.02.2016 09:03так это же бейсик! Я тоже так делал. В 1995 году у меня был советский компьютер БК-0010-01 (на гиктаймсе), в нём при входе сразу включался интерпретатор бейсика (а ещё был ещё один язык Фокал, в котором тоже нужно было ставить номера строк). И там обычно строки нумеровались десятками — 10, 20, 30… Это нужно было как раз для того, чтобы добавить строки между уже добавленными строками.
winox
Больше похоже на первоапрельский пост, на первый взгляд
sayber
На второй взгляд тоже.
У меня к примеру 26 строк на 1080p. (Menlo, 17, 1.7)