Why I love having tabs in source code

Ссылки сюда (1) →

Перевод статьи http://derkarl.org/why_to_tabs.html

Многие делают отступы пробелами. Но в целом, это плохая идея. Если бы табы использовали для отступов, а пробелы — для остального форматирования, проблемы бы не было. По крайней мере современные редакторы, такие как VIM и KWrite, нормально обращаются с табами.

Мои контраргументы к утверждениям статьи «Why I prefer no tabs in source code», агитирующей за пробелы:

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

Если вы используете пробелы без табов, вы никак и никогда не зависите от особенностей и настроек редакторов и просмотрщиков, вам не нужно выставлять им правильную ширину таба. Даже если вы готовы настраивать каждый редактор/просмотрщик под каждую используемую вами платформу, разве вы не усложняете жизнь остальным, кому надо читать и править ваш код?

На самом деле это более переносимо. Я не знаю никого, кто делает отступы пробелами, восемь раз нажимая на пробел, просто они обычно настраивают их текстовый редактор, что таб это восемь пробелов. И неважно, насколько «глубоки» и «широки» ваши табы, читатель просто настроит глубину табов как ему удобно, без необходимости переформатировать файл, ведь переформатирование файла (даже с одним отступом) делает сравнение полностью невозможным, ибо изменяется все! Табы решают эту проблему, можно интерпретировать их как 4-пробельные или 8-пробельные отступы, без изменения файла.

Становится очень сложно читать diff-результаты, как контекстные, так и в формате unified diff, так как там первый столбец означает тип изменения строчки. Для многих разработчиков сейчас это очень важно. И даже если вы разрабатываете ваш код в одиночку, насколько вы уверены, что никому и никогда не взглянет на ваш код, не будет его править и уж совсем никогда не пошлет вам патчи?

Это совершенная неправда, на самом деле, как я выше уже утверждал, отступы с табуляциями упрощают чтение diff-ов.

Становится сложно двигать блоки кода влево-вправо. Например, вы пытаетесь сдвинуть блок на две колонки вправо — и это не действует на строчки начинающиеся с табов.

Конечно, можно сказать все это не потребуется для вменяемые редакторов, которые делают автоматические отступы, но автоматика не всегда может сработать правильно, особенно для Perl-а, когда даже GNU emacs не в силах разобраться с синтаксисом.

И опять таки, вы уверены, что никто кроме вас не захочет переформатировать ваш код?

Автоматическое переформатирование ваших файлов с использованием sed или perl на самом деле гораздо легче, если используются табы, так как каждый уровень задается в точности одним символом, и не надо подсчитывать пробелы, пытаясь определить ширину таба — 8, 4 или сколько там еще пробелов. А редакторы, которые не справляются с табами, — это вовсе не редакторы, а недоразумение (вспоминается emacs).

Аргумент «табы хороши, потому, что каждый может выбрать удобную для себя ширину отступов» не работает, потому что:

• Табы используются не только в начале строк. Может многострочный комментарий, с левым выравниванием текста, но размещенный справа от кода, в общем, вглянем на реальный пример из /usr/include/gmp.h, найденный на FreeBSD-системе:

typedef struct
{
  int _mp_alloc;                /* Number of *limbs* allocated and pointed
                                   to by the D field.  */
  int _mp_size;                 /* abs(SIZE) is the number of limbs
                                   the last field points to.  If SIZE
                                   is negative this is a negative
                                   number.  */
  mp_limb_t *_mp_d;             /* Pointer to the limbs.  */
} __mpz_struct;

И теперь представим бедолагу сидящего за терминалом 80x25, и решившего просмотреть форматированный табами код не из расчета 8 пробелов на таб, ведь это было бы ужасно читать из-за переносов строк или выходу за границы экрана, а задав 2 или 3 пробела на таб. Итак, он печатает less -x2 foo.c и бах — внезапно прямоугольные блоки комментарие справа перестают быть выровненными по левому краю — что за фигня!

Табы используются для отступов, для отступов и только для отступов. Они не предназначены для форматирования текста, для выравнивания колонок, или выстраивания ваших комментариев квадратиками. Пробелы предназначены для этого.

Проблемы могут быть даже если табы только в началах строк. Допустим, какой-то код был написан на emacs с табами по восемь пробелов, но со стилем отступов «Kernighan & Ritchie», где отступы в 5 пробелов. Если emacs настроен на использование табов, строчки с одним отступом будут отбиты пятью пробелами, строчки с двумя отступами будут отбиты табом и двумя пробелами (8 + 2 == 10). Если кто-то еще захочет просмотреть этот код в редакторе/листальщике с табами по 4 пробела, то в строчках с единичной глубиной будет отступ на 5 колонок, следующий уровень — 6 колонок, третий уровень — 11 колонок… Упс!

Во-первых, K&R-стиль давно устарел. Ничего страшного, если вы смените K&R-стиль на табы, где табы ровно X пробелов, и где каждый столбец будет на уровне кратном X.

На самом деле, преимущество табов можно увидеть на примере CVS-репозитория kde.

В основном код там допускает отступы пробелами и большая его часть непоследовательно содержит пробелы и табы вперемешку.

И только малая часть модулей (aRts, Noatun) на 100% последовательна — та, где код форматируется табами.

Лучше делать форматировать так (обозначим табы подчеркиваниями, а пробелы — точками):

_____if.(true)....//This should be replaced
_____{............//with a proper boolean
__________func();
_____}

На любом уровне, все будет выравнено:

SomeClass::SomeClass()
_____.:.InheritingClass(false, false
_____...................5, 10, true,
_____...................bleh, blah)
{
// ....
};

// vim: ts=4 noet

Конференция «Application Developer Days-2010» приглашает участников и докладчиков!

---

Репликация: База Знаний «Заказных Информ Систем» → «Why I love having tabs in source code»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».