Решил я тут полностью перейти на стиль оформления кода согласно стандарту PSR-2. Но являясь противником отступов пробелами (я считаю что SmartTabs это самый правильный вариант), решил изучить вопрос: что написано в стандарте и почему это именно так. Погнали.
Заглянем в текст стандарта и посмотрим что там написано:
В краткой справке пишут что код ДОЛЖЕН использовать 4 пробела, но не табы. Ладно допустим, читаем дальше про этот пункт более подробно.
Опять повторяют краткую справку, о том, что нельзя использовать табы, а надо использовать 4 пробела. И вот далее самое интересное читаем сноску к этому пункту.
Воспользуемся гугл-переводчиком:
«Nb: Использование только пробелы, а не смешивая пространства с вкладками, помогает избежать проблем с файлов изменений, исправлений, истории и аннотации. Использование пространств также делает его легко вставить мелкозернистый суб-отступ для выравнивания между линией.»
С под-отступом понятно, довольно интересная фишка, но я как то никогда ею не пользовался, используется например так:
Но такое как раз и заложено в теории SmartTabs, когда табы используются для отступов от начала строки, а пробелы как раз для таких вот хитрых маневров (и при изменении размера таба основной код будет меняться а код с пробелами всегда останется читаемым независимо от размера таба).
А вот пробелы, как написано в стандарте, используются для того, чтобы не было проблем при работе с системами контроля версий. Вот с этим я и хочу разобраться и проверить так ли это.
1. Создадим два файла, в одном будет код с пробелами в другом, точно такое же код, но уже с табами.
2. Сделаем копии этих файлов и внесем в них изменения.
3. Теперь посмотрим с помощью программы WinMerge
Табы
Пробелы
4. Отправим эти файлы в GIT
5. Посмотрим с помощью программы SourceTree
Табы
Пробелы
6. Посмотрим на сайте Bitbucket
7. Как видим с обычным, не повторяющимся кодом, никаких проблем нет, неважно используются пробелы или табы.
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. При этом если все используется правильно, то код никогда и никуда не уедет.
UPDATE1
Прочитав комментарии я полностью изменил свое мнение по поводу пробелов, проведя данное исследование хотелось разобраться в плюсах 4 пробелов перед табами, тем более тогда мне казалось, что у табов плюсов гораздо больше. Но теперь табы уже не кажутся такими хорошими как раньше. Да, нужно делать как в стандарте, тем более, что так делает большинство, зачем плыть против течения. Но у пробелов тоже есть свои минусы. В общем когда делали стандарт выбрали наименьшее зло из двух возможных (ИМХО).
Но эти холивары похоже будут длится еще довольно долго.
UPDATE2 14.10.2015
По просьбе в комментарии, соберу в одном месте основные моменты почему пробелы лучше табов:
Плюсы конечно натянутые, но до конца всю правду о причинах пробелов против табов знают только те, кто участвовал в разработке стандарта.
Что говорит стандарт
Заглянем в текст стандарта и посмотрим что там написано:
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. При этом если все используется правильно, то код никогда и никуда не уедет.
UPDATE1
Прочитав комментарии я полностью изменил свое мнение по поводу пробелов, проведя данное исследование хотелось разобраться в плюсах 4 пробелов перед табами, тем более тогда мне казалось, что у табов плюсов гораздо больше. Но теперь табы уже не кажутся такими хорошими как раньше. Да, нужно делать как в стандарте, тем более, что так делает большинство, зачем плыть против течения. Но у пробелов тоже есть свои минусы. В общем когда делали стандарт выбрали наименьшее зло из двух возможных (ИМХО).
Но эти холивары похоже будут длится еще довольно долго.
UPDATE2 14.10.2015
По просьбе в комментарии, соберу в одном месте основные моменты почему пробелы лучше табов:
- SmartTabs это конечно здорово, но tzlom в своем комментарии написал, в каком случае даже умные табы хуже пробелов.
- Банально, большинство людей пишут пробелами, там уж повелось исторически (комментарий) от пользователя symbix, также вот пруф
Плюсы конечно натянутые, но до конца всю правду о причинах пробелов против табов знают только те, кто участвовал в разработке стандарта.
