Практически каждый редактор кода под солнцем может обрабатывать более длинные строки. Что делать с упаковкой, должно быть выбором потребителя контента, а не ответственностью создателя контента.
Есть ли (законно) веские причины для присоединения к 79 персонажам в этом возрасте?
Укороченная длина линии повышает производительность за счет увеличения KLOC. : p
Alex
26
Ограничение в 79 символов полностью устарело. Любая скромно сложная кодовая база показывает, как она делает код более неудобным для чтения. Например
Джонатан
6
@Jonathan: выглядит хорошо для меня ...
nperson325681
9
Разве вы не используете инструменты сравнения?
эндолит
Ответы:
129
Большая часть ценности PEP-8 состоит в том, чтобы не давать людям спорить о несущественных правилах форматирования и продолжать писать хороший, последовательно отформатированный код. Конечно, никто на самом деле не думает, что 79 является оптимальным, но нет очевидного выигрыша в его изменении на 99 или 119 или любой другой предпочтительной длине линии. Я думаю, что выбор таков: следуйте правилу и найдите достойную причину для борьбы или предоставьте некоторые данные, которые демонстрируют, как удобочитаемость и производительность зависят от длины строки. Последнее было бы чрезвычайно интересно и имело бы хорошие шансы изменить мнение людей, я думаю.
Большинство исследований по чтению выполняется в дюймах, а не в каждой строке. Правило 66 символов основано на исследованиях, проведенных для чтения газет. Недавние исследования показали, что при чтении онлайн-статей скорость чтения увеличивается примерно до 120 символов в строке (10 дюймов при шрифте 12 размера) без потери понимания.
Пейс
7
На самом деле каждый, кто читает эту тему, считает, что оптимальным является 79 символов. Вот почему он был добавлен в PEP8! Этот ответ на самом деле неверен. Это правильный
erikbwork
6
Я думал, что вопрос о том, почему 79 лучше, чем 80 или 78
n611x007
157
there's no obvious gain in changing it to 99 or 119 or whatever your preferred line length is Это так неправильно во многих отношениях. Оберните строку в 40 символов и скажите, насколько она читаема. Очевидно, что меньше переноса = больше читаемости, если у вас есть место на экране, что в 2015 году у вас есть. Упаковка влияет на читабельность. Читаемость влияет на ремонтопригодность. Ремонтопригодность влияет на качество. И качество влияет, если вы наберете 80 символов. Полная остановка.
Джонатан
6
Спорить о читабельности с чем-либо, не связанным с кодом, бесполезно, поскольку в этих исследованиях предполагается, что текст работает. Код выглядит совершенно по-разному с разной (символьной) длиной строки в каждой строке. И даже если вы пишете до конца строки, отступ меняет количество символов в строке.
Corvince
111
Обеспечение читабельности вашего кода, а не только машинного. Многие устройства по-прежнему могут отображать только 80 символов одновременно. Кроме того, это позволяет людям с большими экранами выполнять несколько задач за счет возможности установки нескольких окон рядом друг с другом.
Читаемость также является одной из причин принудительного отступа строки.
Да, конечно. Но почему 79? Почему не 100 или 120? Хранение вещей читаемым работает в обе стороны. Слишком много чтения кода вверх-вниз тоже трудно.
pcorcoran
17
Это правда, что многие устройства могут отображать только 80 символов. Сколько из них не может выполнить мягкую упаковку?
Джим
39
Кроме того, предпочтительно не иметь перенос кода. С точки зрения пользовательского опыта, это неприемлемо для большинства.
Джастин Бозонье
8
Есть некоторые операционные системы, такие как MVS, которые не могут обрабатывать строки длиной более 72 символов. PEP-8 здесь не поможет. Установка произвольного ограничения в 79 символов не имеет смысла, поскольку то, насколько хороши символы в строке, зависит от редактора, монитора, личных предпочтений пользователя и так далее.
codymanix
96
79 символов также заставляют программистов использовать более короткие и загадочные имена переменных и функций, чтобы все подходило. Это плохо для читабельности.
Герт Стейн
46
Я программист, который ежедневно сталкивается с большим количеством кода. Открытый исходный код и что было разработано в доме.
Как программист, я считаю полезным открывать много исходных файлов одновременно и часто организовывать мой рабочий стол на моем (широкоэкранном) мониторе так, чтобы два исходных файла располагались рядом. Я мог бы программировать на обоих или просто читать одно и программировать на другое.
Я нахожу это неудовлетворительным и разочаровывающим, когда один из этих исходных файлов имеет ширину> 120 символов, потому что это означает, что я не могу удобно разместить строку кода на строке экрана. Это нарушает форматирование для переноса строк.
Я говорю «120», потому что это уровень, до которого меня раздражает, когда код шире. После такого количества символов вы должны разделить строки для удобства чтения, не говоря уже о стандартах кодирования.
Я пишу код с учетом 80 столбцов. Это просто для того, чтобы когда я протекал через эту границу, это не так уж плохо.
«Я пишу код с учетом 80 столбцов. Это просто для того, чтобы, когда я действительно просачивался через эту границу, это было не так уж плохо». Мне то же.
КобеДжон
4
10 лет спустя: не зависит ли это от того, как вы настроили перенос строк. Перенос строки может быть настолько умным или глупым, насколько вы этого хотите. Если читать неудобно, это просто ошибка вашего редактора.
Дэвид Малдер
2
Я кодирую до 120 символов, но иногда дольше, когда это подходит для удобства чтения. Черные форматы на 120, если вы скажете это. PEP-8 также говорит, что «можно увеличить ограничение длины строки до 99 символов», но люди, похоже, подавляют эту информацию большую часть времени. Почти никто не использует терминалы шириной 80. Сообщения журнала никогда не имеют ширину 80.
NeilG
37
Я полагаю, что те, кто изучает типографику, скажут вам, что 66 символов в строке должны быть самой читаемой шириной для длины. Тем не менее, если вам нужно отладить машину удаленно через ssh-сессию, большинство терминалов по умолчанию используют 80 символов, 79 просто подходят, и попытка работать с чем-то более широким становится настоящей болью в таком случае. Вас также удивит количество разработчиков, использующих vim + screen в качестве повседневной среды.
<Flame> Emacs FTW! </ Flame> +1, хотя. Я думаю, что ограничение в 79 происходит с первых дней существования UNIX (и, возможно, MULTICS) с терминалами 80x25 символов.
Джо Д
10
Мои ssh + screen + vim environemnts не имеют проблем с отображением длинных строк.
chrishiestand
54
«Предполагается, что длина строки составляет 66 символов на строку». Я полагаю, мы должны написать код в 2 или 3 столбца, так как газеты так расположены?
Марк Э. Хааз
23
@mehaase: ваше саркастическое замечание очень близко к истине: приличные редакторы могут делать разделенные панели и показывать разные вещи бок о бок (из одинаковых или разных файлов). По совпадению, это обычно возможно только тогда, когда код имеет стандарт длины строки ...
nperson325681
2
@mehaase: звучит здорово, на самом деле. Я не шучу.
Текин
19
Печать моноширинного шрифта с размерами по умолчанию составляет (на бумаге формата А4) 80 столбцов на 66 строк.
Я принимаю этот стандарт; это действительно. Но кто печатает код больше? Кроме того, кто печатает код из среды, которая не допускает масштабирования или других параметров форматирования? Когда в последний раз кто-то из ваших знакомых был озадачен неспособностью отобразить строку из 100 символов?
pcorcoran
3
Почему люди печатают код в 2012 году? Это напоминает мне о том, что я должен был пойти на технологическую конференцию и получить мешок и печатный переплет, полный презентаций. Это люди 21-го века: пошлите мне по электронной почте слайды, иначе сумка и переплет отправляются прямо на свалку.
Марк Э. Хааз
2
так почему 80-1 лучше чем 80-0 или 80-2?
n611x007
11
"по умолчанию размеры" Вы говорите? Расскажите подробнее об этих общепринятых размерах по умолчанию.
Бруно Броноски
15
Да, давайте приоритизируем то, как код выглядит на печатной бумаге выше всего остального.
Джонатан
8
Вот почему мне нравится 80 символов: на работе я использую Vim и работаю одновременно с двумя файлами на мониторе, работающем с разрешением 1680x1040 (я никогда не смогу вспомнить). Если строки больше, у меня проблемы с чтением файлов, даже при использовании переноса слов. Само собой разумеется, я ненавижу иметь дело с кодом других людей, поскольку они любят длинные строки.
разве вы не используете vim для javascript / html?
Послание серебро
2
@eladsilver Я не могу понять, если это шутка? :-D
Стивен Черч
извините, не очень хорошо разбираетесь в vim, очевидно, если вы работаете в сети, вы используете его также для html / js, и эти типы никогда не идут с ограничением в 80 символов, так как разработчики интерфейса не знают о pep8, поэтому ограничение Python для 80 символов является не решит вашу проблему, если вы используете больше, чем только Python. так что я спрашиваю, как вы справляетесь с другими языками программирования?
Серебро
Я работаю в Vim со 120 символьными строками. Я использую: diffthis с горизонтальным разделением. Если вы можете разместить только 160 символов на 1680 пикселях, у вас должен быть большой размер шрифта.
NeilG
4
Поскольку пробел в семантическом смысле имеет семантическое значение, некоторые методы переноса слов могут давать неверные или неоднозначные результаты, поэтому для избежания таких ситуаций должен быть определенный предел. Длина строки в 80 символов была стандартной, так как мы использовали телетайпы, поэтому 79 символов кажутся довольно безопасным выбором.
Есть два разных типа переноса слов. Есть жесткая упаковка, где строки разбиваются на новые строки, и есть мягкая упаковка, где они отображаются только с разрывами, но физически остаются одной строкой. Я не вижу никаких проблем с последним.
Джим
4
Большинство редакторов Python не выполняют мягкую перенос слов, потому что это приводит к неоднозначному трудно читаемому коду на языке, где важны пробелы и отступы.
Крис Апчерч
4
Он не производит двусмысленный или трудно читаемый код, пока обертка каким-то образом идентифицируется. Кейт делает это, и это прекрасно работает. Если редактор не справляется с этим, то это причина подавать ошибку в редакторе, а не причина навязывать стиль кодирования, позволяющий избежать ошибки.
Джим
5
Даже если это указано визуально, это все же делает код намного более трудным для чтения, поэтому редакторы Python обычно не поддерживают его.
Крис Апчерч
Вы действительно пробовали это в течение длительного периода времени? У меня есть. Это не делает код более сложным для чтения по моему опыту. Вы можете подтвердить, что именно поэтому редакторы Python не включают эту функцию? Я никогда не слышал это утверждение раньше.
Джим
1
Я согласен с Джастином. Чтобы уточнить, слишком длинные строки кода труднее читать людям, и некоторые люди могут иметь ширину консоли, которая вмещает только 80 символов в строке.
Рекомендация по стилю предназначена для того, чтобы код, который вы пишете, мог быть прочитан как можно большим количеством людей на как можно большем количестве платформ и максимально комфортно.
Это ленивый аргумент. Не всегда так, что 80 строк вредит читабельности. Беглый взгляд на любую скромно сложную кодовую базу Python, которая заключает в себе 80 строк, на самом деле демонстрирует обратное - что при переносе однострочных вызовов функций на несколько строк усложняется отслеживание WTF.
Джонатан
0
потому что если вы толкаете его за пределы 80-го столбца, это означает, что либо вы пишете очень длинную и сложную строку кода, которая делает слишком много (и поэтому вы должны рефакторинг), либо что вы слишком много отступали (и поэтому вы должны рефакторинг).
-1, я не думаю, что вы можете категорически сказать, что любая строка за границей в 80 символов требует рефакторинга. Методы класса уже имеют два отступа, добавьте еще один отступ для «если» и т. Д. И простое понимание списка, и довольно легко пересечь границу из 80 символов.
42
Не говоря уже о том, что если вы называете символы таким образом, чтобы они были удобочитаемыми для человека, например «users_directed_graph» вместо «usr_dir_gph», то даже простое выражение сожрет довольно много символов в строке.
Марк Э. Хааз
8
Я всегда обнаруживал в Python, что если я превышаю 80 символов, разумно остановиться и подумать, почему это так. Обычно ошибочное дизайнерское решение виновато.
Майк Велла
3
Это был и мой опыт. Он также учитывает более длинные имена переменных, как указывает @mehaase, но я думаю, что это является преимуществом. Доступные комбинации трех последовательных слов (в случае «users_directed_graph») уменьшают количество компонентов, которые разумно вписываются в одно пространство имен. Я считаю, что старый код, который я написал, где много похожих длинных имен переменных находятся в одном и том же пространстве имен, труднее читать и, как правило, лучше реорганизовать.
ТимКлиффорд
4
В языке, который требует отступов для каждого изменения области видимости, утверждение, что 80 символьных строк равны сложности, является чрезмерно упрощенным аргументом. Иногда 80 символов - это то, что нужно для вызова функции. Современные IDE / редакторы для других языков достаточно умны, чтобы распознать это, и могут различить, когда их переносить, в отличие от общих ограничений для всего, что вредит читабельности в целом.
Ответы:
Большая часть ценности PEP-8 состоит в том, чтобы не давать людям спорить о несущественных правилах форматирования и продолжать писать хороший, последовательно отформатированный код. Конечно, никто на самом деле не думает, что 79 является оптимальным, но нет очевидного выигрыша в его изменении на 99 или 119 или любой другой предпочтительной длине линии. Я думаю, что выбор таков: следуйте правилу и найдите достойную причину для борьбы или предоставьте некоторые данные, которые демонстрируют, как удобочитаемость и производительность зависят от длины строки. Последнее было бы чрезвычайно интересно и имело бы хорошие шансы изменить мнение людей, я думаю.
источник
there's no obvious gain in changing it to 99 or 119 or whatever your preferred line length isЭто так неправильно во многих отношениях. Оберните строку в 40 символов и скажите, насколько она читаема. Очевидно, что меньше переноса = больше читаемости, если у вас есть место на экране, что в 2015 году у вас есть. Упаковка влияет на читабельность. Читаемость влияет на ремонтопригодность. Ремонтопригодность влияет на качество. И качество влияет, если вы наберете 80 символов. Полная остановка.Обеспечение читабельности вашего кода, а не только машинного. Многие устройства по-прежнему могут отображать только 80 символов одновременно. Кроме того, это позволяет людям с большими экранами выполнять несколько задач за счет возможности установки нескольких окон рядом друг с другом.
Читаемость также является одной из причин принудительного отступа строки.
источник
Я программист, который ежедневно сталкивается с большим количеством кода. Открытый исходный код и что было разработано в доме.
Как программист, я считаю полезным открывать много исходных файлов одновременно и часто организовывать мой рабочий стол на моем (широкоэкранном) мониторе так, чтобы два исходных файла располагались рядом. Я мог бы программировать на обоих или просто читать одно и программировать на другое.
Я нахожу это неудовлетворительным и разочаровывающим, когда один из этих исходных файлов имеет ширину> 120 символов, потому что это означает, что я не могу удобно разместить строку кода на строке экрана. Это нарушает форматирование для переноса строк.
Я говорю «120», потому что это уровень, до которого меня раздражает, когда код шире. После такого количества символов вы должны разделить строки для удобства чтения, не говоря уже о стандартах кодирования.
Я пишу код с учетом 80 столбцов. Это просто для того, чтобы когда я протекал через эту границу, это не так уж плохо.
источник
Я полагаю, что те, кто изучает типографику, скажут вам, что 66 символов в строке должны быть самой читаемой шириной для длины. Тем не менее, если вам нужно отладить машину удаленно через ssh-сессию, большинство терминалов по умолчанию используют 80 символов, 79 просто подходят, и попытка работать с чем-то более широким становится настоящей болью в таком случае. Вас также удивит количество разработчиков, использующих vim + screen в качестве повседневной среды.
источник
Печать моноширинного шрифта с размерами по умолчанию составляет (на бумаге формата А4) 80 столбцов на 66 строк.
источник
Вот почему мне нравится 80 символов: на работе я использую Vim и работаю одновременно с двумя файлами на мониторе, работающем с разрешением 1680x1040 (я никогда не смогу вспомнить). Если строки больше, у меня проблемы с чтением файлов, даже при использовании переноса слов. Само собой разумеется, я ненавижу иметь дело с кодом других людей, поскольку они любят длинные строки.
источник
Поскольку пробел в семантическом смысле имеет семантическое значение, некоторые методы переноса слов могут давать неверные или неоднозначные результаты, поэтому для избежания таких ситуаций должен быть определенный предел. Длина строки в 80 символов была стандартной, так как мы использовали телетайпы, поэтому 79 символов кажутся довольно безопасным выбором.
источник
Я согласен с Джастином. Чтобы уточнить, слишком длинные строки кода труднее читать людям, и некоторые люди могут иметь ширину консоли, которая вмещает только 80 символов в строке.
Рекомендация по стилю предназначена для того, чтобы код, который вы пишете, мог быть прочитан как можно большим количеством людей на как можно большем количестве платформ и максимально комфортно.
источник
потому что если вы толкаете его за пределы 80-го столбца, это означает, что либо вы пишете очень длинную и сложную строку кода, которая делает слишком много (и поэтому вы должны рефакторинг), либо что вы слишком много отступали (и поэтому вы должны рефакторинг).
источник