wps.su

Когда я начал программировать, поначалу я использовал табы. Но потом я понял, что они плохо подходят для работы. Они вроде бы обещают гибкость, но на практике это не совсем так, и вы все равно привязываете других разработчиков к вашему стилю отступов (indentation). Если вы привязываете других разработчиков к вашему стилю, зачем тогда вообще использовать табы, которые могут привести к путанице?

Что рекомендуют стандарты по оформлению кода?

Посмотрим, что говорится по поводу табов и пробелов в общепринятых стандартах по оформлению кода на примере PHP (PSR-2) и Python (PEP 0008).

PSR-2:

Code MUST use 4 spaces for indenting, not tabs.

PEP 0008:

Spaces are the preferred indentation method.
Tabs should be used solely to remain consistent with code that is already indented with tabs.

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

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

Но мы пойдем дальше.

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

Табы с шириной 4 символа

На примере ниже показан код, который везде использует табы с шириной 4 символа.

function foo() {
    var someVar = 1,                            // Какая-то переменная
        anotherVariable = 2,                    // Другая переменная
        isThing = someVar === anotherVariable;  // Проверка

    if (someVar === otherVar)   bar();      // Условие
    else if (isThing)           otherFn();  // Что-то делаем
    else                        quux();     // Что-то еще делаем

    function bar() {
        if (anotherVariable === 42) {       // Еще одно условие
            anotherFunction();
        }
    }
}

Все выглядит отлично, когда для таба установлена ширина 4 символа. Но, стоит попробовать изменить ширину таба в вашей IDE, и все аккуратное выравнивание собьется. Да, тот факт, что можно изменить ширину таба это круто. Но если это требует переформатирования кода, то это не самая лучшая особенность использования табов.

Табы с шириной 2 символа

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

function foo() {
  var someVar = 1,                            // Какая-то переменная
      anotherVariable = 2,                    // Другая переменная
      isThing = someVar === anotherVariable;  // Проверка

  if (someVar === otherVar) bar();      // Условие
  else if (isThing)         otherFn();  // Что-то делаем
  else                      quux();     // Что-то еще делаем

  function bar() {
    if (anotherVariable === 42) {       // Еще одно условие
      anotherFunction();
    }
  }
}

Табы только для отступов внутри блоков

А что, если использовать табы только для отступов внутри блоков? Некоторые люди считают это решением проблемы, присутствующей в примерах выше. Этот способ имеет свои сложности, если мы хотим сделать выравнивание чего-либо, находящегося на разных уровнях вложенности блоков, а также вызывает резонный вопрос: "А зачем?". Ведь форматирование отступов блоков это самое простое, что умеет IDE, и переформатировать эти отступы в нормальных IDE можно очень легко.

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

Пробелы вместо табов

Самая большая выгода от того, чтобы полностью отказаться от табов и использовать пробелы - это корректные, надежные отступы. Нету ни малейшей возможности запутаться, так как то, что вы видите, то вы и получите. Не нужно устанавливать еще кучу дополнительных правил и исключений, специфичных для варианта с табами, не нужно беспокоиться, что кто-то случайно нарушил эти правила. В любой момент можно без опасения скопировать код из IDE и вставить на stackoverflow, github, jsfiddle, в консольный редактор, textarea и т.д. И вы получите актуальный, читаемый код. Не опасаясь, что ваши табы растянутся на 8 символов.

В дополнение к этому, когда мы используем пробелы, код становится "самоописываемым". То есть, если мы видим два пробела, то мы знаем, что ориентир - это отступ размером в два символа. Если же мы видим таб и поехавшее выравнивание, то нам придется поэкспериментировать, прежде чем мы поймем, в соответствии с каким же стилем писал изначально код разработчик.

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