Pull to refresh

Comments 84

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

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

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

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

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

Но и ограничение в 80 символов — просто смешно, половина монитора пустует.
UFO landed and left these words here
Это да, но есть же средства для борьбы с callback-hell'ом.
UFO landed and left these words here
Ну, например, когда на JS пишешь для Node.js там периодически бывают оооочень глубокие отступы

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

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

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

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

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

Но мы-то живем в будущем, и эти воробьи давно вымерли, а вместе с ними пропала и потребность в гаубице для стрельбы по ним.
UFO landed and left these words here
Условия можно разбить на несколько булевских переменных. Так даже проще разбираться.
UFO landed and left these words here
> Исходный код … не «читают»

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

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

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

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

f(
a,
b,
c,
)

а стало

f(
a,
b,
c,
d,
)

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

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

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

чтоб else одной строкой можно было удалить
UFO landed and left these words here
В питоне можно и так написать

func(
a,
b,
c,
d,
)

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

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

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

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

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

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

Так что граница 80-символов ещё актуальна.
Пишу на xslt, сделал табы в 2 пробела, но один фиг некоторые конструкции в длину могут превышать 200 знаков. Не вижу в этом проблемы в силу специфики самого языка.
Да, язык говно, с этим спорить сложно
По сравнению с возможными альтерантивами в моей ситуации — он великолепен и полностью решает все возложенные на него задачи. Многобукаф — не самый отвратный вариант.
UFO landed and left these words here
UFO landed and left these words here
Раз уж Вы сами упомянули Kdiff3, то можете поглядеть в сторону пункта Toggle Split Orientation в меню Window. Иногда очень пригождается.
Да, я его в горизонтальном сплите всегда использую.
Одна из самых смешных вещей, которые я встречал в чужом коде — это костыль, спрятанный табами куда-то за границу >200 символа. Вот идешь по коду в отладке, прыгаешь со строки на строку, а происходит черти-что. Я раз 10 проходил это место в отладчике, пока заметил горизонтальный скрол.
На GitHub без горизонтальной прокрутки влезает 124 символа, в диффе 104, так что 100 в самый раз.
На каком разрешении?
Only those users with full accounts are able to leave comments. Log in, please.