Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 84
Ох, что тут сейчас будет…
разрешение монитора тут не причём, исходный код должен быть простым и читаемым
Соглашаюсь с предыдущим комментатором. Чем короче строки, тем легче он читается. А читабельность кода — один из залогов его надежности.
Именно так. Исходный текст должен быть простым и читаемым. И шрифт, а в конечном счете и разрешение экрана здесь играют не последюю роль. Ниже есть комментарий, про, примерно половину экрана в IDE, я с этим постулатом согласен.
Я здесь говорю про ту проблему, которая для многих, на мой взгляд не очевидна. Исходный текст должен оставаться читаемым не только в IDE, но и при мёрже, где текста должно вмещаться на экран в два или в три раза больше, и он должен, по прежнему, оставаться читемым.
Я здесь говорю про ту проблему, которая для многих, на мой взгляд не очевидна. Исходный текст должен оставаться читаемым не только в IDE, но и при мёрже, где текста должно вмещаться на экран в два или в три раза больше, и он должен, по прежнему, оставаться читемым.
Когда какая-нибудь функция библиотеки или API (да хотя бы в том же WinAPI), которые не можешь изменять, десяток параметров, то в одну 80-симаольную строку все-равно все не влезет.
Даже не подозревал что существует такая граница. Сам стараюсь писать, чтобы ширина текста была немного больше половины монитора — так читать удобнее.
Для действительного удобного чтения и восприятия информации строка текста должна охватываться одним взглядом, без поворота головы, это значительно упрощает чтение, поэтому я за 80-120.
Поставил в редакторе границу в 120 для работы существующим проектом, но стараюсь разбивать строку пораньше.
Психологически дискомфорт в том, что как 120, так и 100 — числа, взятые с потолка и ничем логически не обоснованные.
Психологически дискомфорт в том, что как 120, так и 100 — числа, взятые с потолка и ничем логически не обоснованные.
Вставлю свои 5 копеек, раз уж выбрал вариант «Напишу свой вариант».
Писать время от времени приходится на массе разных ЯП, но наиболее часто на PHP (PSR2 говорит о 80-120 символах) и Python (PEP8 — 79 символов). Сам обычно придерживаюсь 50-70 символов, со строгим ограничением в 120 (для комментариев, или когда разбиение на несколько строк значительно ухудшает восприятие).
Но если отбросить все эти стандарты и привычки, то мне кажется, что компактный по ширине код воспринимается легче, т.к. глаза меньше бегают по горизонтали.
Писать время от времени приходится на массе разных ЯП, но наиболее часто на PHP (PSR2 говорит о 80-120 символах) и Python (PEP8 — 79 символов). Сам обычно придерживаюсь 50-70 символов, со строгим ограничением в 120 (для комментариев, или когда разбиение на несколько строк значительно ухудшает восприятие).
Но если отбросить все эти стандарты и привычки, то мне кажется, что компактный по ширине код воспринимается легче, т.к. глаза меньше бегают по горизонтали.
Есть ещё момент правки файлов через терминал или в виртуальной машине. Конечно современные терминалы позволяют расширить обзорную часть, но если открыто несколько окон, удобнее их держать в компактном виде. Из этого вытекает одно из правил, который я стараюсь блюсти — не писать код больше одного экрана.
Я использую границу 80 символов. В подавляющем большинстве случаев удаётся укладывать строки в этот предел.
Конечно, нужно руководствоваться здравым смыслом, и иногда можно выйти за эти границы на несколько символов, так как строка такой длины будет более читаемой, чем разбитая.
Конечно, нужно руководствоваться здравым смыслом, и иногда можно выйти за эти границы на несколько символов, так как строка такой длины будет более читаемой, чем разбитая.
Если вы пишете на современном языке и вам надо написать очень длинную строчку (или не длинную, но с большим отступом слева) — вы, скорее всего, что-то делаете не так.
Но и ограничение в 80 символов — просто смешно, половина монитора пустует.
Но и ограничение в 80 символов — просто смешно, половина монитора пустует.
Это да, но есть же средства для борьбы с callback-hell'ом.
Ну, например, когда на JS пишешь для Node.js там периодически бывают оооочень глубокие отступы
Не бывают. Ну если, конечно, вы не забываете о нормальной архитектуре, разбиваете код на подпрограммы, а не пишете лапшу в стиле Джуниоров.
Вложеность в 4 таба — это уже редкость.
Мне тут заявили, что лучше 6 табов и 5 экранов текста, чем 5 функций по 2 таба и одному экрану
Стараюсь писать код компактно, но без конкретного ограничения на длину строки. Там, где это уместно, строка получается длиннее 80-ти символов.
Иногда без длинной строки просто не обойтись. Например, на языке SASS иначе просто не написать. Получается некрасиво (пример), но что поделать… IDE (JetBrains IDEA) выручает, позволяя включать line wraps индивидуально для отдельных файлов.
Текст (всякие README.md, пример: рендер, исходник) никогда не переношу. Дело в том, что если делать переносы, то дописывание текста превращается в мучение. Добавил пару строк, сиди, исправляй переносы для всего абзаца.
Иногда без длинной строки просто не обойтись. Например, на языке SASS иначе просто не написать. Получается некрасиво (пример), но что поделать… IDE (JetBrains IDEA) выручает, позволяя включать line wraps индивидуально для отдельных файлов.
Текст (всякие README.md, пример: рендер, исходник) никогда не переношу. Дело в том, что если делать переносы, то дописывание текста превращается в мучение. Добавил пару строк, сиди, исправляй переносы для всего абзаца.
Дело в том, что если делать переносы, то дописывание текста превращается в мучение. Добавил пару строк, сиди, исправляй переносы для всего абзаца.Очередной пример превосходства Vim над другими жалкими редакторами. ;)
А зачем тогда переносить?
Горячо плюсую. Я в восторге, как Vim позволяет перемещаться по коду, не меняя положения правой руки.
Однако следует понимать, что Vim — это набор древних костылей, превратившийся в автоматическую гаубицу.
Почему в Vim есть навигация по коду при помощи клавиш-букв? Потому что в 70-е годы на клавиатурах не было клавиш-стрелок.
Почему Vim автоматически корректирует переносы? Потому что в 70-е годы оборудование и ПО не было совместимо с длинными строками.
Но мы-то живем в будущем, и эти воробьи давно вымерли, а вместе с ними пропала и потребность в гаубице для стрельбы по ним.
Однако следует понимать, что Vim — это набор древних костылей, превратившийся в автоматическую гаубицу.
Почему в Vim есть навигация по коду при помощи клавиш-букв? Потому что в 70-е годы на клавиатурах не было клавиш-стрелок.
Почему Vim автоматически корректирует переносы? Потому что в 70-е годы оборудование и ПО не было совместимо с длинными строками.
Но мы-то живем в будущем, и эти воробьи давно вымерли, а вместе с ними пропала и потребность в гаубице для стрельбы по ним.
Условия можно разбить на несколько булевских переменных. Так даже проще разбираться.
> Исходный код … не «читают»
Вон из профессии!
Вон из профессии!
его не «читают»Некоторые считают иначе: Seven Pillars of Pretty Code
К сожалению, сайт perforce переделали, и оригинальная ссылка больше не доступна.
80, но не жёстко. Если по читаемости получается лучше не переносить (как правило, в сложных выражениях), не переношу.
Жёсткая — где-то 100 или 120.
Жёсткая — где-то 100 или 120.
Emacs, C-x 3 на 22'' мониторе — в самый раз для 80 символов.
Слишком маленькие строчки — плохо.
У нас есть человек, который настаивает на следующем:
fuc(a,
b,
c,
d,
e,
f)
И получается такая портянка… Зато мерджится хорошо, особенно если программа не показывает изменения в строке.
У нас есть человек, который настаивает на следующем:
fuc(a,
b,
c,
d,
e,
f)
И получается такая портянка… Зато мерджится хорошо, особенно если программа не показывает изменения в строке.
Ужас! А какой язык, если не секрет?
python
Правда конечно переменные не однобуквенные. Но это ад. Было 10 строчек, а теперь 2 экрана.
Правда конечно переменные не однобуквенные. Но это ад. Было 10 строчек, а теперь 2 экрана.
Гм, а почему бы не
?
tmp_x = fuc(a, b, c, d, e, f)
# используем tmp_x
?
Если давать осмысленные имена переменным и правильно расставлять отступы, то 80 символов порой не хватает. У меня как то исторически сложилась граница в 100 символов. Более длинная — уже не всегда охватишь взглядом. Ну и конечно, граница не жесткая. Если что то не помещается на пару символов — я прощаю. Форматирование по ширине автоматическое.
80 — наше все. Как кто-то в свое время отметил, «Вертикальный лайаут кода стимулирует короткие фразы на нем, заставляет разработчика писать не вширь, а вглубь».
Стараюсь писать код как можно короче (<80), но если ради читаемости или удобства восприятия необходимо больше пространства прибегаю к этому.
Из своего опыта я сталкивался с потребностью в длинных строках когда:
1. Много параметров у метода — ртешение: использовать либо структуру для передачи параметров, либо метод выполняет слишком много действий и в итоге требует рефакторинга.
2. Условие из слишком много условий — решение: зарефакторить таким образом чтобы большая часть условий вычислялись заранее и присваивались коротким но осмысленным переменным, либо вынос условий в методы (часто не один метод).
3. Выражение по вычислению чего-либо слишком длинное. решение: разбить на куски и по отдельности вычислить либо вынести кое-что в методы.
4. Вырежение-вызов метода с не большим количеством параметров, но содержащий длинные идентификаторы (10+ символов). В принципе такое можно отрефакторить но не всегда. Вот такие случаи:
— Укоротить идентификаторы невозможно, потому что читабильность уменьшится.
— Вынести расчет параметров в отдельности невозможно потому что они и так записаны как идентификатор на переменную.
В итоге подобная ситуция может вылится в 100-120 символов. Что никогда не была проблемой для меня и моих коллег.
В итоге наличие длинных строк ситуция оооочень редкая, но не критичная с моей точки зрения.
ЗЫ: Пишу на Java.
Из своего опыта я сталкивался с потребностью в длинных строках когда:
1. Много параметров у метода — ртешение: использовать либо структуру для передачи параметров, либо метод выполняет слишком много действий и в итоге требует рефакторинга.
2. Условие из слишком много условий — решение: зарефакторить таким образом чтобы большая часть условий вычислялись заранее и присваивались коротким но осмысленным переменным, либо вынос условий в методы (часто не один метод).
3. Выражение по вычислению чего-либо слишком длинное. решение: разбить на куски и по отдельности вычислить либо вынести кое-что в методы.
4. Вырежение-вызов метода с не большим количеством параметров, но содержащий длинные идентификаторы (10+ символов). В принципе такое можно отрефакторить но не всегда. Вот такие случаи:
— Укоротить идентификаторы невозможно, потому что читабильность уменьшится.
— Вынести расчет параметров в отдельности невозможно потому что они и так записаны как идентификатор на переменную.
В итоге подобная ситуция может вылится в 100-120 символов. Что никогда не была проблемой для меня и моих коллег.
В итоге наличие длинных строк ситуция оооочень редкая, но не критичная с моей точки зрения.
ЗЫ: Пишу на Java.
Границу повесил на 120, стараюсь не вылезать, но не фанатично (ага, в xml совсем не вылезать...). Проблема с мёржем/дифом отлично решается двумя мониторами.
PS мне читать узкие колонки гораздо сложнее, чем широкие строки. И ридер и планшет при чтении я переворачиваю в горизонтальное разрешение.
PS мне читать узкие колонки гораздо сложнее, чем широкие строки. И ридер и планшет при чтении я переворачиваю в горизонтальное разрешение.
Как пользователь спектрума настаиваю на границе в 64 символа. Иначе не влазит в строку на 50см телевизоре (разрешение 256х192).
Как пользователь мониторов с разрешением 2560х1440 воспринимаю ваши слёзы по поводу «не влазит на 1920» как ретроградство.
Как пользователь мониторов с разрешением 2560х1440 воспринимаю ваши слёзы по поводу «не влазит на 1920» как ретроградство.
Как теперь будут выглядеть три копии Вашего исходного текста в 120 символов шириной каждая на Вашем мониторе с всего 1920 пикселей шириной?
У меня два монитора. 3-х точечный мердж использую редко, а два монитора идеальны для обычного.
Код пишу так, чтобы строчка влезала на экран монитора. Становится удобно писать громоздкие языковые конструкции, давать длинные и ясные имена переменным и тп.
Посмотрел — почти все строки вмещаются в 160 символов.
Не понимаю, какой смысл открывать текстовый редактор на весь экран — всё равно большинство строк короткие. Лучше открыть IDE на полэкрана или разбить редактор на два файла но горизонтали.
Так что граница 80-символов ещё актуальна.
Так что граница 80-символов ещё актуальна.
Пишу на xslt, сделал табы в 2 пробела, но один фиг некоторые конструкции в длину могут превышать 200 знаков. Не вижу в этом проблемы в силу специфики самого языка.
Люблю классику.
Раз уж Вы сами упомянули Kdiff3, то можете поглядеть в сторону пункта Toggle Split Orientation в меню Window. Иногда очень пригождается.
Одна из самых смешных вещей, которые я встречал в чужом коде — это костыль, спрятанный табами куда-то за границу >200 символа. Вот идешь по коду в отладке, прыгаешь со строки на строку, а происходит черти-что. Я раз 10 проходил это место в отладчике, пока заметил горизонтальный скрол.
На GitHub без горизонтальной прокрутки влезает 124 символа, в диффе 104, так что 100 в самый раз.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Правая граница в исходном тексте