Дослідження оптимальної ширини коду?

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

Моє запитання: чи існують дослідження, які показують, що насправді 80 символів є максимальною максимальною шириною для читабельності коду, чи це значення є лише «таким, як це було завжди», і ніхто насправді не знає, чому це так? І чи повинна ширина рядка коду входити до вашого стандарту кодування?

Насправді річ на 80 стовпців довгий час передує DOS. Він походить від карткових ударів, які були пристроями на 80 колон.

А щоб відповісти на питання ОП, одне "дослідження" триває вже близько 600 років - друкована книга. Вони еволюціонували впродовж століть, маючи на увазі читальність перш за все, до положення, в якому зараз ми перебуваємо, коли середня довжина рядка для тексту становить близько 60 символів. Тож для читабельності йдіть на більш вузькі поля.

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

Причини віддати перевагу 80:

• Читається з більшим шрифтом на ноутбуках

• Залишає місце для розміщення двох версій поряд для порівняння

• Залишає місце для перегляду навігації в IDE

• Друкує без довільного порушення рядків (також стосується електронної пошти, веб-сторінок, ...)

• Обмежує складність в одному рядку

• Обмежує відступ, що в свою чергу обмежує складність методів / функцій

Так, це повинно бути частиною стандарту кодування.

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

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

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

Якось я працював у Visual Studio на екрані 1920x1200. Я б максимізував це, коли всі вікна інструментів стиковані на одну сторону. Було достатньо місця для двох вікон редактора поряд із 100 символами.

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

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

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

• Я (майже) ніколи не використовую кілька заяв в одному рядку
• Я використовую лише довгі рядки (> 12), лише якщо лінії, схожі на них, можна вирівняти та не зламати.
• Я завжди використовую достатньо пробілів / дужок тощо
• Я віддаю перевагу більш довгі імена змінних вище коротших імен

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

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

Можливо, 80 символів також є хорошим моментом, щоб уникнути цих поганих ланцюжків:

object.getFoo().getBar().getFooBar().get ...

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

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

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

1. Людські очні яблука круглі, не дуже вузькі та широкі, і більша частина їх роздільної здатності знаходиться посередині . Коли читаєте години за один раз, набагато зручніше розводити очі короткими дугами, використовуючи одну смугу прокрутки, якщо потрібно. Я не знаю формального дослідження, що стосується розбірливості коду, але з моїх власних спостережень, монітор на відстані 2 футів, розміром тексту на 10-кратне односхилий шрифт, 100 символів займає приблизно 1/3 мого горизонтального поля зору, або близько 60 градусів ( поза 30 градусів або близько того, де знаходиться дозвіл усіх очей ).
2. Більшість людей використовують великий монітор на роботі, щоб вони могли бачити кілька речей, не клацаючи вперед і назад, не так, щоб вони бачили одне дійсно велике.
3. Короткі рядки містять меншу складність, що, сподіваємось, змушує розробника розбиватися, перетворюючи їх код на більш засвоювані одиниці.

Я чітко пам’ятаю, що десь читав (я думаю, це було в Agile Documentation ), що для оптимальної читабельності ширина документа повинна становити приблизно два алфавіти, або 60-70 символів. Я думаю, що ширина ліній старих терміналів була частково від того старого типографічного правила.

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

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

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

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

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

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

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