Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[intensive] пробелы ➡ табы #1097

Open
3 tasks
baileys-li opened this issue Apr 1, 2023 · 7 comments
Open
3 tasks

[intensive] пробелы ➡ табы #1097

baileys-li opened this issue Apr 1, 2023 · 7 comments

Comments

@baileys-li
Copy link

baileys-li commented Apr 1, 2023

Мы же все понимаем, что рано или поздно кто-то бы открыл это ишью.
Думаю первое апреля лучшая дата. 😉

Я больше всего удивляюсь, что в той серии Кремниевой Долины, та чувиха внатуре печатала пробелы через пробел. Просто конченная.

Проблема

Тема холиварная, тема срачегенная, но давайте взглянем сначала на аргументы, которые можно легко верифицировать.

Почему табы лучше 😺

  • Меньший размер. Один символ, понятное дело, меньше чем минимум два. Просто возьмите любой файл, где много строк и отступов, и сравните размер с табами и пробелами. Капля в море, но все равно меньше байтов по сети гонять, сервера меньше греются, глобальное потепление отодвигаем чуть-чуть-чуть-чуть-чуть дальше.
  • Настраиваемые. Можно у себя локально поменять принятый в команде размер, если не подойдёт. Или там где отступы влияют на код, сделать побольше, чтобы в .py или .pug точно не перепутать попадает ли код в if блок или нет. С пробелами надо всё переформатировать и следить за тем, чтобы не пошло в коммит. Это дополнительные трудности, которых нет на табах.
  • Доступные. Это следует из предыдущего пункта, но так важно, что стоит выделить отдельно. Слабовидящие могут локально у себя поменять размер и они не помешают другим разработчикам.

Почему пробелы лучше 💩

  • Легаси. Так просто привыкли.
    • Но это важно? Миллионы мух не могут ошибаться? Люди привыкли к jQuery, но это не повод не переходить на ECMAScript.
    • У Вадима Макеева было видео, что табы во всём лучше, но он перешел на пробелы, потому что в open source приносят ПР, которые конфликтуют с кодгайдом. Но это странный аргумент, потому что хороший разработчик должен уметь подстраиваться под кодгайд проекта. И студентов мы этому тоже учим. Почему любители табов идут навстречу и понимают, что в проектах может быть установленный кодгайд, а любители пробелов нет? Это не справедливо.
    • Кейс Макеева все равно не подходит под студентов Академии, потому что они не разрабатывают либы, где много контрибьютеров. Проекты в рамках курсов идут в основном в их портфолио и то до поры, пока у них не будут рабочие кейсы.
  • Некоторые форматы принимают только пробелы. Это действительно проблема. Вот бы мы давали студентам какой-то инструмент который позволял настраивать отступы для конкретных форматов файлов <подмиг-подмиг>.

Дополнительно

Это уже больше вкусовщина и не относиться к прямому применению, но табы это буквально символ для оступов. Точно так же как многоточие это , а не ...; тире — это , а не -; в русском языке кавычки это «ёлочки». Если у вас тоже что-то вроде перфекционизма или ОКР, то возникает жгучее желание использовать "правильный" символ вместо "неправильного". (тут кавычки не «ёлочки», потому что я их в воздухе показываю)

Это как семантика в HTML.

Вывод

Табы объективно лучше.

Решение

В шаблонах проектов меняем настройки .editorconfig на:

root = true

[*]
charset = utf-8
end_of_line = lf
tab_width = 4
indent_style = tab
insert_final_newline = true
trim_trailing_whitespace = true

[*.md]
trim_trailing_whitespace = false

[*.{yaml,yml}]
indent_style = space
indent_size = 2

Для YAML делаем отдельное исключение, потому что они воспринимают только пробелы. Возможно есть ещё какие-то форматы, но для курсов HTML/CSS и JS ничего больше в голову не приходит.

Для курсов JS долнительно вносим правило в ESLint:

rules:
  indent: [error, tab]

Ну и чтобы в ручную не фиксить все отступы в шаблонах, воспользоваться npm пакетом

npx eclint fix .
# Либо pnpx, если в системе стоит pnpm
# pnpx eclint fix .

Он deprecated и там зависимости старые, но для одноразовых применений сойдёт.

Чеклист

Preview Give feedback
@firefoxic
Copy link
Contributor

firefoxic commented Apr 2, 2023

Люто плюсую!

Я уже рассказывал в слаке историю с конфигом для своих студентов, но слак тю-тю, поэтому повторю тут.

Не поверив в поинт, что автопроверка на защитах за конфигами бежит куда-то на сервер академии, а не в сам проект, я решил проверить в бою на паре студентов, предупредив их, что возможно придётся через пару минут (после моего пуша с исправлением табов на пробелы) тыкнуть в создание архива и отправку на допуск ещё раз. Но не пришлось ничего тыкать, ибо автопроверка таки в конфиги проекта смотрит. И казалось бы на этом эксперимент можно было бы завершить, моя гипотеза была доказана. Если бы не одно «но»…

Включил я им табы в начале курса (и заодно сразу пояснил, что теперь они могут в любой момент в настройках выставлять любой удобный размер отступа, не влияя на diff в git). А под конец курса я поймал себя на мысли, что именно у этих студентов за весь курс не было в коде никаких косячков с отступами. Если с остальными мне приходилось постоянно отвлекаться на всякие 13 пробелов вместо ожидаемых 14, то с участниками эксперимента у меня всё внимание было на саму вёрстку, а не вот это вота всё.

Само собой с тех пор я стал всем менять конфиг. И на html1, и на html2. И мне меньше отвлекаться на ерунду, и студентам удобнее.


Кстати, о Вадиме: когда на него не давят «толерантные» пробельщики, он таки использует табы. Только вот tab_width я бы не фиксировал. В VSCode и так по дефолту 4. И не уверен, что с зафиксированным будет легко сменить на удобное отдельному разработчику значение (надо будет проверить).

@efiand
Copy link

efiand commented Jul 8, 2023

Плюсую!

И тоже не советую фиксировать tab_width, а, напротив, использовать indent_size: tab - чтобы размер подстраивался под настройки редактора пользователя, кому как удобно. Мне удобно два, кому-то 4. В этом ведь одно из преимуществ таба над пробелами.
Гитхаб и гитлаб также идут по этому пути, позволяя кастомить ширину таба в отображаемом коде.

@efiand
Copy link

efiand commented Jul 8, 2023

Также я бы добавил такое

[*.svg]
# Векторные изображения могут храниться в минифицированном виде, лишняя строка не нужна
insert_final_newline = false

@firefoxic
Copy link
Contributor

Векторные изображения могут храниться в минифицированном виде, лишняя строка не нужна

Editoconfig не ругался у меня ни разу на svg, съёженные в одну строку без EOL в конце.

@efiand
Copy link

efiand commented Jul 8, 2023

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

@firefoxic
Copy link
Contributor

использовать indent_size: tab - чтобы размер подстраивался под настройки редактора пользователя

У меня совсем без этого параметра такое же поведение: работает настройка размера таба в редакторе.

@efiand
Copy link

efiand commented Jul 8, 2023

У меня совсем без этого параметра такое же поведение: работает настройка размера таба в редакторе.

Возможно, в некоторых редакторах были несоответствия с дефолтными настройками расширения editorconfig, но откуда-то я помню, что это решало проблемы. Можно попробовать без нее, по мере возникновения трудностей создать ишью уже с пруфами.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants