Существуют ли объективные причины для использования пробелов вместо вкладок для отступа файлов согласно стандарту PSR-2, может кто-то предоставить:
на чем основан стандарт PSR-2?
Авторы стандарта PSR-2 имели в виду нечто большее, чем «выглядеть и чувствовать», нечто большее, чем просто основанные на мнении вещи, и многим людям трудно понять, почему пространства лучше во время совместной работы.
Согласно ответу Фарсайда: репозитории могут быть точным случаем того, почему пробелы в PSR-2 объясняются как инструмент отступа. PSR-2 является стандартом, разработанным для облегчения командной работы. Отдельные случайные пробелы в начале строки — при использовании вкладок — могут быть не видны в IDE и могут проникнуть в хранилище. Если несколько человек работают над одним файлом, очень возможно создать ненужные конфликты. Использование пробелов вместо вкладок позволяет легко обнаружить такое случайное пространство на глазном яблоке, и это, вероятно, причина, почему их использование становится стандартом.
Исходя из моего опыта, мы столкнулись с нашими проектами: GIT и другие системы контроля версий лечить невидимым spaces
+ TABS
иначе, и это приводит к изменениям в строках, которые фактически не были затронуты. Легко не заметить, когда будет случайно добавлен один space
+ TAB
= indent выглядит одинаково в IDE, но GIT будет иметь значение при слиянии. Это повредит вашей способности эффективно сравнивать ревизии в системе контроля версий, что действительно страшно. Это никогда не произойдет, когда у вас есть spaces
только.
Ширина вкладки (в пробелах) зависит от вашей среды (текстовый редактор, ОС, настройки и т. Д.), Но ширина пространства везде одинакова. Среды IDE достаточно умны, чтобы обрабатывать пробелы по своему вкусу, но результаты, полученные для совместной работы, должны соответствовать стандартам.
Использование пробелов вместо вкладок связано с 8,6% более высокая зарплата. Использование пробелов вместо вкладок связано с такой большой разницей в зарплате, как дополнительный 2,4-летний опыт работы. (источник: Stack Overflow 2017 Опрос разработчиков).
Если каждый сотрудник вашего проекта будет придерживаться одних и тех же стандартов кодирования — это будет хорошо в долгосрочной перспективе, совместная работа будет более эффективной и профессиональной, такой же отступ, когда вы будете проводить рефакторинг или разработку. Исследования относительно этого:
Например, Бен Шнейдерман подтвердил это в Исследовательские эксперименты в поведении программиста:
когда программные заявления были расположены в разумном порядке, Эксперты смогли запомнить их лучше, чем новички. Когда заявления были перетасованы, превосходство экспертов уменьшилось.
Старое исследование 1984 года Солоуэй и Эрлих цитируется в Код завершен, и поддержал исследования из Элементы стиля программирования:
Наши эмпирические результаты ставят зубы под эти правила: Это не просто вопрос эстетики, что программы должны быть написаны в определенном стиле. Скорее, существует психологическая основа для написания программ обычным способом: у программистов есть большие надежды на то, что другие программисты будут следовать этим правилам дискурса. Если правила нарушены, тогда полезность, заложенная ожиданиями, которые программисты создали со временем, фактически аннулирован.
Других решений пока нет …