Why I prefer no tabs in source code

Adam Spiers «Почему в коде я предпочел бы обойтись без табов»

Перевод статьи Why I prefer no tabs in source code

Я заметил, что несколько человек зашло на мою статью с статьи Why I love having tabs in source code, где автор пытается оппонировать моим аргументам против использования табов. (Замечу также, что автор весьма невежливо не поставил меня в известность о своей заметке, и, тем самым, не дал мне удобной возможности ответить). Он поднял интересные вопросы, правда проигнорировал некоторые мои. Хотя возможно он просто их не понял, тогда это моя вина, что я сформулировал их более ясно. Если выдастся время, я попробую это исправить и ответить на его заметку с более конкретными, проясняющими мою позицию, примерами.

Итак, вернемся к моей статье.

Многие программисты смешивают в исходниках пробелы с табами — символами табуляции с ASCII-кодом 09, вместо того, чтобы использовать несколько (обычно 8) пробелов вместо таба. Да, это считается малозначительной вкусовщиной, но я считаю, что, как правило, это не шибко удачная идея, и ниже я поясню почему.

«Как правило» — это потому, что в любом правиле есть исключения, которые подтверждают все правила без исключения. Ниженаписанное относится в основном к свободному софту, потому что из-за «базарной»^[1] модели разработки высока публичность кода. Однако если вам не повезло, и вы работаете в компании не оставляющей никому выбора ни для правил отступов, ни текстового редактора, то, что поделать — эта статья вам все равно не пригодится.

Итак, это:

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

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

Вообще у diff есть пара решений для этого — опции --expand-tabs и --initial-tab, но ни оба из них недостаточны.

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

Конечно, можно сказать все это не нужно, если у вас вменяемый редактор, делающий автоматический отступ, но автоматика не всегда срабатывает верно, особенно для Perl-а, когда даже GNU 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 колонок… Упс!

Этот же аргумент можно адресовать и к пробелам. Хотите взглянуть на исходники, чтобы двухколоночные отступы показывались как четырехколоночные? Без проблем:

$ perl -pe 's/^((  )+)/$1$1/' foo.c | less

Хотите переформатировать 8-колоночные отступы в трехколоночные? Легко:

$ perl -pi -e 's/^( +)\1{7}/$1 x 3/e' foo.c

Очевидно, можно написать простой Perl-скрипт или макрос для редактора, чтобы сделать эти операции еще более простыми.

А вы что думаете?

Я всегда интересуюсь чужой точкой зрения на этот вопрос. Может я что-то упустил? Или даже вы попробуете доказать мне что, я ошибаюсь?!

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

Будь любезен, сделай всем одолжение! Напиши в свое ~/.emacs:

(setq-default indent-tabs-mode nil)

или в своей ~/.vimrc:

:set expandtab

Пишите, пожалуйста, мне, как это сделать в других текстовых редакторах.

Отзывы и мнения остальных

У полубога Линуса есть свои собственные заповеди, с некоторыми из которых я согласен.I agree with.

Dawn Endico указал что известных нетскейпщик/мозильщик Jamie Zawinski тоже написал заметку по теме, аргументы которой схожи с моими, но изложение несколько отличается. Рекомендую взглянуть!

Неизвестный доброжелатель послал мне пачку ссылок по теме. Я был рад узнать, что в целом, там со мной согласны :-)

Возможно самая лучшая страничка с защитой табов, из тех что я видел. Я согласен почти со всем, кроме того что диффы выглядят отлично. Еще он забыл про цитирование кода при email-переписке.
Стиль отступов в стандарте C++.
Стиль кодирования для Python
http://www.rudbek.com/Code_gui.htm#Guideline_No_Hard_Tabs
http://babbage.cs.qc.edu/courses/cs101/Coding_Guidelines.html
FreeBSD style guide
How To Write Unmaintainable Code
http://xarg.net/writing/tabs
Coding standards for the Jakarta Project

Robert Swindell указал мне на интересное предложение «PT/SC», где параметры форматирования, такие, как ширина табов, хранятся в заголовке плоского текстового файла в едином, человекочитаемом формате. Давайте надеятся, что редакторы вскорости станут его поддерживать…

Примечания

↑ Метафора отсылает к известному эссе «Собор и Базар» о конкурирующих парадигмах разработки корпоративного и свободного программного обеспечения.

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

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

[1] Метафора отсылает к известному эссе «Собор и Базар» о конкурирующих парадигмах разработки корпоративного и свободного программного обеспечения.

[1]

Персональные инструменты

Просмотры

Why I prefer no tabs in source code

Материал из CustisWiki

Отзывы и мнения остальных

Примечания