Вертикальне вирівнювання: так чи ні? [зачинено]

Наприклад, не вертикально вирівняні:

Name:   Hamt
Version:  0.1.0
Cabal-Version:  >= 1.2
License:  BSD3
Author:  Jason Baker

Або вертикально вирівняні:

Name:           Hamt
Version:        0.1.0
Cabal-Version:  >= 1.2
License:        BSD3
Author:         Jason Baker

Якому ви віддаєте перевагу і чому?

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

Економить час, коли ви просто так робите:

Name: Hamt
Version: 0.1.0
Cabal-Version: >= 1.2
License: BSD3
Author: Jason Baker

Чи не надто важко для читання.

Я віддаю перевагу гібриду:

Name    : Hamt
Version : 0.1.0
Cabal-Version :  >= 1.2
License : BSD3
Author  : Jason Baker

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

Ось ще одна зміна макетів списків, заснованих як на досвіді, так і на освіті з курсу університету, який я взяв на взаємодію людина-комп'ютер та декілька книг, які я прочитав про (G) дизайн інтерфейсу та графічний дизайн. Я використовую його для діалогів, і коли у мене є енергія / час, для CSS (хоча зазвичай не для коду).

          Name : Hamt
       Version : 0.1.0
 Cabal-Version : >= 1.2
       License : BSD3
        Author : Jason Baker

Як і всі інші, він має свої плюси і мінуси.

Плюси:

• Сильний зоровий розрив відокремлює дані від міток
• Естетичний, професійний вигляд графічного дизайну (особливо для доопрацьованих, опублікованих файлів)
• Дані ближче до мітки, що робить його легше асоціювати (зменшує шанси на читання через рядок до неправильних даних)
• Ідеально підходить для макетів діалогового вікна

Мінуси:

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

HTH

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

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

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


Щодо моїх двох центів, я віддаю перевагу варіанту другої версії. Мені це найкраще подобається:

Name            : Hamt
Version         : 0.1.0
Cabal-Version   : >= 1.2
License         : BSD3
Author          : Jason Baker

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

По-перше, я зазвичай віддаю перевагу табличним таблицям на відміну від пробілів, однак фактична настройка TAB змінюється; наприклад, я звик до 4-пробільних таблиць TAB для коду C (++) або HTML та 2-пробільних таблиць для коду Pascal або Assembler, тоді як для деяких речей, таких як CSS, я не віддаю переваги ширині TAB. Ця варіація досить ускладнює речі, але тоді редактор, який я використовую, кидає в своїх власних ускладненнях. Деякі редактори дозволяють встановлювати налаштування TAB для кожної мови, а деякі не (навіть деякі, які мають різні профілі).

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

Я взагалі віддаю перевагу табличним таблицям, тому що навіть з кодом фіксованої ширини, мені стає неприємно переходити курсор через декілька пробілів для кожної ТАБ. Я пам’ятаю, що у старих IDE Borland була можливість курсору через TAB (конкретно цілі довжини пробілу) як єдине ціле, а не через два, чотири тощо. Це зробило практичним вставлення таблиць TAB як пробілів, роблячи навігацію курсором легкою та швидкою. На жаль, я не бачив жодних сучасних редакторів Windows, які могли б це зробити.

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


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