Чи є поважна причина застосування максимальної ширини 80 символів у кодовому файлі цього дня та віку? [зачинено]

Серйозно. На 22-дюймовому моніторі він охоплює, можливо, чверть екрана. Мені потрібно трохи патронів, щоб зменшити це правило.

Я не кажу, що не повинно бути обмеження; Я просто кажу, що 80 символів дуже мало.

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

• Щоб уникнути обгортання під час копіювання коду в електронну пошту, веб-сторінки та книги.
• Для перегляду декількох джерел вікон поруч або за допомогою диспетчера розбіжностей.
• Для поліпшення читабельності. Вузький код можна швидко прочитати без необхідності сканувати очі з боку на бік.

Я думаю, що останній пункт є найважливішим. Хоча за останні кілька років екрани зросли в розмірах та роздільній здатності, очі не стали .

Початок форматування тексту у 80 стовпцях - раніше, ніж термінали з 80 стовпцями - перфокарта IBM датується 1928 роком ! Це нагадує про (апокрифічну) історію про те, що залізнична колія США визначалася шириною колісних коліс у Римській Британії.

Інколи мені здається, що це трохи звужує, але має сенс мати деякий стандартний ліміт, тож це 80 стовпців.

Ось та сама тема висвітлена і Slashdot .

А ось старенька заява Фортран:

80 символів - це смішна межа в ці дні. Розділіть рядки коду там, де це має сенс, а не відповідно до будь-яких довільних обмежень символів.

Ви повинні зробити це заради всіх, хто не має 22-дюймового широкоекранного монітора. Особисто я працюю на 17-дюймовому моніторі 4: 3, і вважаю це більш ніж досить широким. Однак у мене також є 3 таких монітора, тому у мене ще багато корисного екранного простору.

Мало того, але людське око насправді має проблеми з читанням тексту, якщо рядки занадто довгі. Занадто просто загубитися, в якій лінії ви знаходитесь. Газети розміром 17 дюймів (або щось подібне), але ви не бачите, як вони пишуть по всій сторінці, це стосується журналів та інших друкованих видань. Це насправді простіше читати, якщо ви тримаєте стовпчики вузькими.

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

Я заперечую, що наступне набагато читабельніше, ніж було б, якби я розділив його на кілька рядків:

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

Оновлення: У коментарі було припущено, що це буде більш стислим способом виконання вищезгаданого:

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY; 

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

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

Я використовую перевагу великих екранів, щоб поруч мати кілька фрагментів коду.

Ви не отримаєте у мене ніяких патронів. Справді, мені б не хотілося, щоб це змінилося, оскільки в надзвичайних ситуаціях я все ще бачу рідкісні випадки, коли мені потрібно змінити код з текстової консолі.

Наддовгі рядки важче читати. Тільки тому, що на моніторі ви можете набрати 300 символів, це не означає, що ви повинні робити такі лінії довгими. 300 символів також занадто складні для заяви, якщо у вас немає вибору (дзвінок, який потребує цілого ряду параметрів.)

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

Єдине, що я змушую залишатися в межах 80 символів - це моє коментування.

Особисто ... Я присвячую всі свої сили мозку (що там мало) правильному кодуванню, боляче повертатися назад і розбивати все на межі 80 знаків, коли я можу витратити свій час на наступну функцію . Так, Resharper міг би зробити це для мене, я думаю, але тоді це трохи злякає мене від того, що сторонній продукт приймає рішення щодо мого коду і змінює його ("Будь ласка, не розбивайте мій код на два рядки HAL. HAL?" ).

Однак, я працюю над досить маленькою командою, і всі наші монітори є досить великими, тому переживаючи, що турбує моїх колег-програмістів, це не викликає великого занепокоєння.

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

У мене є два монітора 20 "1600x1200, і я дотримуюся 80 стовпців, тому що це дозволяє мені відображати декілька вікон текстового редактора поруч. Використовуючи шрифт" 6x13 "(шрифт trad. Xterm) 80 стовпців займають 480 пікселів плюс смугу прокрутки і рамки вікон. Це дозволяє мати три вікна цього типу на моніторі 1600х1200. У вікнах шрифт Lucida Console цього не зробить (мінімальний корисний розмір шириною 7 пікселів), але монітор 1280x1024 відображатиме два стовпці та монітор 1920x1200, такий як HP LP2465 , відображатиметься 3. Він також залишить трохи місця для різних дослідників, властивостей та інших вікон від Visual Studio.

Крім того, дуже довгі рядки тексту важко читати. Для тексту оптимальним є 66 символів. Є момент, коли надмірно довгі ідентифікатори починають бути контрпродуктивними, оскільки їм важко складати кодове узгоджено. Хороший макет та відступ забезпечує наочні підказки щодо структури коду, а деякі мови (Python приходить на думку) використовують відступ явно для цього.

Однак бібліотеки стандартного класу для Java та .Net мають тенденцію до переваги дуже довгих ідентифікаторів, тому не можна обов'язково гарантувати можливість цього робити. У цьому випадку викладення коду з розривами рядків все ще допомагає зробити структуру явною.

Зверніть увагу , що ви можете отримати вікно версію «6x13» шрифтів Тут .

Люди кажуть, що довгі рядки коду, як правило, складні. Розглянемо простий клас Java:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

Це 94 символи, а назва класу досить коротка (за стандартами GWT). Було б важко читати в 2 рядках, і це дуже легко читається на одному рядку. Будучи прагматичним щодо цього і таким чином дозволяючи "зворотній сумісності", я б сказав, що 100 символів - це правильна ширина.

Інші відповіді вже добре підсумували речі, але також варто врахувати, коли ви хочете скопіювати та вставити якийсь код в електронний лист, а якщо не - код, то розл.

Це час, коли мати «максимальну ширину» корисно.

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

Наступна людина, у якої може бути 17-дюймовий екран або може знадобитися великий шрифт, щоб прочитати текст. Обмеження має бути десь і 80 символів - це умова через попередні обмеження екрана. Чи можете ви придумати будь-який новий стандарт (120) та Чому корисно використовувати інше, то "ось що відповідає моєму монітору в шрифті Xpt?"

Пам'ятайте, що з кожного правила завжди є винятки, тому у вас є певний рядок або блок коду, який має сенс бути більше 80 символів, а потім бути бунтарем.

Але спершу подумайте, "чи справді цей код такий поганий, що він не може жити протягом 80 символів?"

У стандарті кодування Linux вони не тільки зберігають обмеження 80 символів, але й використовують 8 відступів у просторі.

Частина міркувань полягає в тому, що якщо ви коли-небудь досягнете правильної межі, вам слід розглянути можливість переміщення рівня відступу в окрему функцію.

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

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

Правий запас - це спосіб природи, який підказує вам виконати додатковий метод рефакторингу .

Цікаво, чи це може спричинити більше проблем у цей день та вік. Пам'ятайте, що в C (і, можливо, інших мовах) існують правила, наскільки тривалим може бути ім'я функції. Тому ви часто бачите дуже важко зрозумілі імена в коді С. Хороша річ у тому, що вони не використовують багато місця. Але кожен раз, коли я дивлюсь на код якоюсь мовою, як C # або Java, назви методів часто дуже довгі, що робить його неможливим утримати код у довжину 80 символів. Я не думаю, що сьогодні 80 символів є дійсними, якщо вам не потрібно мати можливість надрукувати код тощо.

Як автор керівних принципів кодування для мого роботодавця я збільшив довжину рядка з 80 до 132. Чому це значення? Ну, як зазначали інші, 80 - це довжина багатьох старих апаратних терміналів. І 132 так само! Це ширина лінії, коли клеми знаходяться в широкому режимі . Будь-який принтер також може робити паперові копії в широкому режимі зі стислим шрифтом.

Причиною не залишатися в 80 є те, що я скоріше

• віддайте перевагу довшим іменам зі значенням для ідентифікаторів
• не турбуйтеся з typedefs за структури та перерахунки на C (вони BAD, вони приховують корисну інформацію! Запитайте Петра ван дер Лінден у "Deep C Secrets", якщо ви не вірите), тож у коді є більше, struct FOO func(struct BAR *aWhatever, ...)ніж у коду фанатиків typedef .

і за цими правилами лише 80 символів / рядків спричиняють некрасиві загортання ліній частіше, ніж мої очі вважають прийнятними (переважно в прототипах та визначеннях функцій).

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

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

Використовуйте пропорційні шрифти.

Я серйозно. Зазвичай я можу отримати еквівалентність 100-120 символів у рядку без шкоди для читабельності чи друку. Насправді це навіть простіше читати за допомогою гарного шрифту (наприклад, Verdana) та синтаксичного забарвлення. Це виглядає трохи дивним протягом декількох днів, але ти швидко звикаєш до цього.

Я намагаюся утримати речі близько 80 символів з простої причини: занадто багато, ніж це означає, що мій код стає занадто складним. Занадто багатослівні назви властивостей / методів, назви класів тощо завдають стільки ж шкоди, скільки і лаконічні.

Я головним чином кодер Python, тому це створює два набори обмежень:

1. Не пишіть довгі рядки коду
2. Не відступайте занадто багато

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

У Python легко писати відносно короткий код (див. Codegolf) за рахунок читабельності, але ще простіше писати багатослівний код за рахунок читабельності. Хелперські методи не є поганою справою, а також не допомагають заняттями. Надмірна абстракція може бути проблемою, але це ще одна проблема програмування.

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

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

Ви код - це лише одна частина середовища.

Я не повинен застосовувати 80 символів - означає врешті-решт загортання слова.
ІМО, будь-яка довжина, обрана для лінії максимальної ширини, не завжди підходить, і можливе відповідь наведення тексту на слова.
І це не так просто, як це звучить.

Він реалізований в jedit _{(джерело: jedit.org ),} який пропонує обгортання слів

Але вона гірко пропускається в затемненні з довгого часу ! (фактично з 2003 року), головним чином тому, що обгортання слів для редактора тексту включає:

• Інформація про вкладений рядок призначена для перегляду тексту, навігації по коду, вертикальних лінійок.
• Інформація про нерозгорнутий рядок необхідна для таких функцій, як готична лінія, стовпець лінійки нумерації рядків, підсвітка поточної лінії, файл збереження.

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

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

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

Я цілодобово відрізняюся, і у мене немає чудового 22-дюймового монітора. Я не знаю, чи буду коли-небудь. Звичайно, це мало цікавить програмістів лише для запису, які користуються стрілочним кодуванням та 300-знаковими рядками.

Так, оскільки навіть у цей день та вік деякі з нас кодують на терміналах (нормально, переважно термінальні емулятори), де дисплей може відображати лише 80 символів. Отже, принаймні за кодування, яке я роблю, я дуже ціную правило 80 char.

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

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

Зміна 80 символів - це те, що ви робите під час кодування, а не згодом. Те саме з коментарями, звичайно. Більшість редакторів можуть допомогти вам побачити, де знаходиться обмеження 80 символів.

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

Якби ми мали один з них , ми б не маючи цю дискусію! ;-)

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

Питання фрагментів коду електронної пошти має певні заслуги. Але з огляду на злі речі, які робить більшість клієнтів електронної пошти заздалегідь відформатованим текстом, я думаю, що обгортання рядків є лише однією з ваших проблем.

Щодо друку, я зазвичай вважаю, що 100 символьних ліній дуже зручно розмістяться на друкованій сторінці.

Я намагаюся тримати рядки нижче 80 стовпців. Найсильнішою причиною є те, що я часто опиняюся за допомогою grepта lessпереглядом свого коду під час роботи в командному рядку. Мені дуже не подобається, як термінали переривають довгі лінії джерела (адже вони не створені для цієї роботи). Ще одна причина полягає в тому, що я вважаю, що це виглядає краще, якщо все вписується в рядок і не порушується редактором. Наприклад, параметри довгих функціональних дзвінків добре вирівняні один під одним і подібні речі.