Чому слід використовувати відступ стовпців для поліпшення читабельності коду

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

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

Чотири приклади вдосконалень із використанням відступу коду

Перший приклад

Погляньте на цей код:

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

І ваші сім рядків перетворились на майже 40 рядків. Це лише три-чотири властивості на об’єкт. Якби це було вісім властивостей, то стало б 70 рядків.

Ідея, про яку я говорю, полягає у використанні приблизно такого (я називаю це кодом із відступом у стовпці):

Другий приклад

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

Його також можна використовувати в JS import . Порівняйте ці дві версії:

Ці тринадцять імпортів впорядковано за алфавітом шляхом. Всі вони з vsпапки - п’ять з vs/baseі вісім з vs/platform.

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

Тепер подивимося, як це виглядає, коли той самий код має відступ у стовпці:

Хіба це не робить це трохи кращим?

Третій приклад

У цьому прикладі ми маємо декларацію методу від компілятора TypeScript:

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

Четвертий приклад

Ось останній приклад, з оригіналом та порівнянням разом:

Плюси :

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

Мінуси :

  • Параметр автоматичного форматування редакторів коду може заважати макету
  • Додаючи один рядок до блоку рядків, іноді доводиться міняти всі інші рядки
  • Написання коду може зайняти багато часу

Які інструменти можуть допомогти цього досягти?

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

Я використовую Visual Studio та Visual Studio Code, тому спробував знайти розширення або плагін, які допомагають цього досягти. Я не знайшов жодного. Тож у листопаді 2017 року я почав створювати власне розширення для Visual Studio Code і назвав його Smart Column Indenter.

Того ж місяця я опублікував першу корисну версію. Погляньте, як це працює:

Є сфери, де розширення можна покращити. В даний час він працює тільки з *.ts, *.jsі *.jsonфайли. Я думаю, що це також може допомогти з файлами XML та HTML, наприклад, з відступом по стовпцях однакових атрибутів повторюваних тегів або різних тегів, що повторюються в групі рядків.

Після вибору коду для відступу стовпців алгоритм працює в три етапи:

  1. Лексичний аналіз (або токенізація) коду. Я встановив пакунок TypeScript npm як залежність і використовував API компілятора, щоб уникнути повторного винаходу колеса.
  2. Виконайте алгоритм найдовшої загальної послідовності (LCS), передаючи кожен рядок коду як послідовність лексем. Це найскладніша частина. Багато посилань в Інтернеті говорять про LCS лише для двох послідовностей як вхідних даних, що легко вирішується за допомогою динамічного програмування . Оскільки ми зазвичай хочемо робити відступи у стовпцях більше двох рядків коду, проблемою стає пошук найдовшої загальної послідовності (LCS) з декількох рядків. Це NP-важка проблема. Оскільки це загальна проблема, для цього я створив окремий пакет npm (multiple-lcs) з базовою реалізацією. У деяких випадках це не найкраще рішення, але воно діє.
  3. Перепишіть код, щоб відступи кодувати маркери, що з’являються в LCS, робили відступи. Кожен маркер в LCS розміщується в новому стовпці.

Для деяких типів маркерів, таких як імена рядків або змінних, замість вмісту в алгоритмі LCS використовується ім’я типу. Результатом є більша підпослідовність.

Я помістив всю логіку в окремий пакет npm (smart-column-indenter). Якщо ви хочете створити подібне розширення або плагін для іншої IDE на основі JavaScript, ви можете використовувати цей пакет.

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

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

Дякуємо за читання.

Оновлення (2018–03–29): Після його публікації кілька днів тому я отримав багато відгуків, більшість із них є негативними, але все одно дякую усім, добре знати, чому багато людей не люблять це. Пізніше я дізнався, що люди зазвичай називають це "вирівнюванням коду", ви не знайдете нічого про "відступ стовпців", тому, якщо ви хочете дізнатись більше про це, замість цього знайдіть "вирівнювання коду". Я зробив це, і я знайшов цікавий допис у блозі Теренса Ідена, оскільки більшість негативних коментарів стосуються проблем зі злиттям VCS, історії та брудних відмінностей, я скопіюю його висновок: «Якщо наші інструменти змусять розуміння цих ідей більше важко, це інструменти, які потрібно змінити - не ми ".

Оновлення (2018–05–03): Ніби хтось із команди GitHub читав тут негативні коментарі щодо вирівнювання коду, тепер ви можете ігнорувати пробіли в огляді коду.

Оновлення (2018–05–20): Якщо ви використовуєте Visual Studio (не Code), Шадман Кудчікар зробив подібне розширення, ви можете прочитати про нього тут або завантажити тут.

Фактоїдний

Зараз у нас 22-дюймові екрани з роздільною здатністю 1920x1080. Немає жодних причин обмежуватися 80 символами в рядку, хоча вам потрібно визначитися з максимальним обмеженням. Походження цього обмеження в 80 символів: