PSR-2, анализ одного пункта стандарта. Пробелы или табы

от автора

Решил я тут полностью перейти на стиль оформления кода согласно стандарту PSR-2. Но являясь противником отступов пробелами (я считаю что SmartTabs это самый правильный вариант), решил изучить вопрос: что написано в стандарте и почему это именно так. Погнали.

Что говорит стандарт

Заглянем в текст стандарта и посмотрим что там написано:

1. Overview
Code MUST use 4 spaces for indenting, not tabs.

В краткой справке пишут что код ДОЛЖЕН использовать 4 пробела, но не табы. Ладно допустим, читаем дальше про этот пункт более подробно.

2.4. Indenting
Code MUST use an indent of 4 spaces, and MUST NOT use tabs for indenting.

Опять повторяют краткую справку, о том, что нельзя использовать табы, а надо использовать 4 пробела. И вот далее самое интересное читаем сноску к этому пункту.

N.b.: Using only spaces, and not mixing spaces with tabs, helps to avoid problems with diffs, patches, history, and annotations. The use of spaces also makes it easy to insert fine-grained sub-indentation for inter-line alignment.

Воспользуемся гугл-переводчиком:

«Nb: Использование только пробелы, а не смешивая пространства с вкладками, помогает избежать проблем с файлов изменений, исправлений, истории и аннотации. Использование пространств также делает его легко вставить мелкозернистый суб-отступ для выравнивания между линией.»

С под-отступом понятно, довольно интересная фишка, но я как то никогда ею не пользовался, используется например так:

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

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

Ставим эксперимент №1

1. Создадим два файла, в одном будет код с пробелами в другом, точно такое же код, но уже с табами.

2. Сделаем копии этих файлов и внесем в них изменения.

3. Теперь посмотрим с помощью программы WinMerge

Табы

Пробелы

4. Отправим эти файлы в GIT

5. Посмотрим с помощью программы SourceTree

Табы

Пробелы

6. Посмотрим на сайте Bitbucket

7. Как видим с обычным, не повторяющимся кодом, никаких проблем нет, неважно используются пробелы или табы.

Ставим эксперимент №2

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

2. Создадим два файла, у которого после изменений будут повторяющиеся куски кода. И также сделаем копии этих файлов и внесем в них изменения.

3. Теперь посмотрим с помощью программы WinMerge

Табы

Пробелы

4. Отправим эти файлы в GIT

5. Посмотрим с помощью программы SourceTree

Табы

Пробелы

6. Посмотрим на сайте Bitbucket

7. Внезапно, что с табами что с пробелами проблема видна невооруженным глазом и ни одна из программ не смогла правильно понять где произошли изменения. Тогда к чему в стандарте написано, что пробелы позволяют решить проблему: helps to avoid problems with diffs, patches, history, and annotations.

В качестве заключения

Так может быть стоит плюнуть на этот пункт стандарта и использовать SmartTabs, ведь преимущества использования табов в начале строки неоспоримы. Табы можно настроить как нравится, хочешь как два пробела, хочешь как 4, а хочешь как 8 или даже 3. При этом если все используется правильно, то код никогда и никуда не уедет.

ссылка на оригинал статьи http://habrahabr.ru/post/266903/