Чому PEP-8 визначає максимальну довжину рядка 79 символів? [зачинено]

Чому в цьому тисячолітті Python PEP-8 повинен визначати максимальну довжину рядка 79 символів?

Практично кожен редактор коду під сонцем може обробляти більш довгі рядки. Що робити з обгортанням, повинен бути вибір споживача вмісту, а не відповідальність творця контенту.

Чи є (законно) вагомі причини прихильності 79 символів у цьому віці?

Велика цінність PEP-8 полягає в тому, щоб зупинити людей, що сперечаються щодо невластивих правил форматування, і продовжувати писати хороший, послідовно відформатований код. Звичайно, ніхто насправді не вважає, що 79 оптимально, але немає очевидного виграшу в зміні його на 99 або 119 або будь-якої бажаної довжини лінії. Я думаю, що вибір наступний: дотримуйтесь правила і знайдіть вагому причину для боротьби або надайте деякі дані, які демонструють, як читабельність та продуктивність змінюються залежно від довжини рядка. Останнє було б надзвичайно цікавим і матиме гарний шанс змінити думку людей, я думаю.

Зберігання людського коду читабельним, а не машиночитаним. На багатьох пристроях одночасно може відображатися лише 80 символів. Крім того, людям з більшими екранами полегшується багатозадачність, маючи можливість встановити кілька вікон поруч.

Читання також є однією з причин примусового відступу рядків.

Я програміст, якому доводиться щодня стикатися з великою кількістю коду. Відкритий код і те, що було розроблено в будинку.

Як програміст, мені здається корисним відкрити багато вихідних файлів одночасно і часто організовувати робочий стіл на моєму (широкоекранному) моніторі, щоб два вихідні файли були поруч. Я можу програмувати в обох або просто читати одне і програмувати в іншому.

Мені здається незадоволеним і засмучуючим, коли один із цих вихідних файлів має ширину> 120 символів, тому що це означає, що я не можу комфортно розмістити рядок коду на рядку екрана. Це порушує форматування для обертання рядків.

Я кажу "120", тому що це рівень, на який я би роздратувався, коли код ширший за. Після цього багато символів, ви повинні розділити по рядках для читабельності, не кажучи вже про стандарти кодування.

Я пишу код на увазі 80 стовпців. Це просто так, що коли я просочуюся через цю межу, це не так вже й погано.

Я вважаю, що ті, хто вивчає типографію, скажуть вам, що 66 символів на рядок повинні бути найбільш читабельною шириною за довжиною. Тим не менше, якщо вам потрібно віддалено налагодити машину протягом сеансу ssh, більшість терміналів за замовчуванням до 80 символів, 79 просто підходить, намагання працювати з чим-небудь ширшим стає справжнім болем у такому випадку. Вас також здивує кількість розробників, які використовують vim + екран як щоденне середовище.

Друк однобічного шрифту за замовчуванням розміром (на папері А4) становить 80 стовпців на 66 рядків.

Ось чому мені подобається 80-символьний: на роботі я використовую Vim і працюю над двома файлами одночасно на моніторі, на якому працює, я думаю, 1680x1040 (я ніколи не пам'ятаю). Якщо рядків більше немає, у мене виникають проблеми з читанням файлів, навіть при використанні обгортання слів. Потрібно сказати, що я ненавиджу спілкуватися з кодом інших людей, оскільки вони люблять довгі рядки.

Оскільки пробіл має семантичне значення в Python, деякі методи загортання слів можуть давати неправильні або неоднозначні результати, тому для уникнення цих ситуацій потрібно мати деяку межу. Довжина рядка в 80 символів була стандартною, оскільки ми використовували телетипи, тому 79 символів здаються досить безпечним вибором.

Я згоден з Джастіном. Для уточнення, занадто довгі рядки коду важче читати людині, а деякі люди можуть мати консольні ширини, що вміщують лише 80 символів на рядок.

Рекомендація щодо стилю є для того, щоб код, який ви пишете, міг читати якомога більше людей на якомога більшій кількості платформ і максимально комфортно.

тому що якщо ви висунете його за межі 80-го стовпця, це означає, що або ви пишете дуже довгий і складний рядок коду, який робить занадто багато (і тому ви повинні рефактор), або що ви занадто сильно відрізали (і тому ви повинні рефактор).