Как автоматически удалять пробелы в конце строк в VS Code

Что именно удаляет files.trimTrailingWhitespace

Настройка действует при сохранении файла и убирает пробелы или табы после последнего содержательного символа строки. Это отличается от форматирования кода: никакой formatter не нужен, порядок токенов, indentation в начале строки и стиль скобок не меняются. Функция полезна там, где линтер ругается на trailing whitespace или Git показывает мелкие изменения в строках, которые никто не хотел менять. Официальная документация VS Code подтверждает, что `files.trimTrailingWhitespace` применяется на save и работает также с Auto Save. Но есть контексты, где пробелы в конце несут смысл. Самый известный пример — Markdown: в некоторых стилях два конечных пробела создают жёсткий перенос строки. Поэтому не стоит автоматически применять правило к абсолютно любому типу файла, не проверив формат. VS Code поддерживает language-specific settings, так что исключение можно сделать точечно, не отключая очистку для исходного кода.

Совет: После включения настройки сохраните один тестовый файл и посмотрите diff — это быстрее выявит неожиданные значимые пробелы, чем массовый save всего workspace.

Как включить очистку и не сломать Markdown

1. Откройте Settings и найдите `trim trailing whitespace`, либо откройте `settings.json`.
2. Установите `files.trimTrailingWhitespace: true` на нужном уровне: User для всех проектов или Workspace только для текущего репозитория.
3. Сохраните обычный исходный файл с намеренно добавленными пробелами в конце строки и убедитесь, что они исчезли.
4. Если проект использует Markdown с двумя пробелами как line break, добавьте `[markdown]` и внутри `files.trimTrailingWhitespace: false` либо согласуйте другой Markdown-стиль.
5. Проверьте Auto Save: настройка применяется и при автоматическом сохранении, поэтому случайное открытие старого файла может сразу создать diff после срабатывания save.
6. Перед массовой очисткой репозитория закоммитьте функциональные изменения и выполните отдельный whitespace-only commit, если затрагивается много файлов.

Предупреждение: При Auto Save массовое открытие/редактирование legacy-файлов может создать неожиданный diff. Не включайте очистку посреди большого незакоммиченного изменения без проверки.

Где лучше включать настройку

• User. Личная привычка во всех проектах. Legacy/Markdown проект может иметь другие правила
• Workspace. Единое правило конкретного репозитория. Нужно согласовать с командой
• [language]. Исключение Markdown или отдельного формата. Language-specific настройка имеет приоритет
• Trim Trailing Whitespace. Разовая очистка. Не предотвращает появление новых пробелов

Почему лучше не путать trimming и formatter on save

Если после сохранения меняется не только конец строк, но и кавычки, запятые, переносы, indentation или порядок импортов, это уже работа formatter/code actions, а не `files.trimTrailingWhitespace`. Для прозрачной настройки отделите эти механизмы: сначала включите trimming и проверьте минимальный diff, затем отдельно решайте, нужен ли formatOnSave. Это особенно важно в старом проекте, где полный formatter может переписать тысячи строк. Команда Trim Trailing Whitespace существует и как ручное действие с клавиатурным shortcut, поэтому разовую очистку можно выполнить без постоянной настройки. Но для предотвращения возврата проблемы автоматический режим практичнее. В командной среде полезно дополнить editor-настройку линтером или pre-commit проверкой, если отсутствие trailing whitespace действительно является стандартом репозитория: тогда правило будет одинаковым не только у пользователей VS Code.

Важно: Editor-настройка улучшает локальный workflow, но не заменяет проверку в CI, если правило обязательно для всей команды.

Как сделать чистый whitespace-only commit

Сначала убедитесь, что рабочее дерево не содержит несвязанных изменений. Затем включите настройку или выполните ручную команду только для выбранных файлов, сохраните и посмотрите `git diff --check`: Git умеет показывать whitespace-errors и помогает заметить лишние проблемы. Не запускайте Save All во всём монорепозитории, пока не знаете, сколько файлов затронет Auto Save/trim. Если diff большой, ограничьте миграцию каталогом или типом файлов. В commit message явно укажите, что изменение удаляет trailing whitespace без функциональной правки. Это облегчает review и позволяет использовать blame с пониманием причины массового изменения. Для Markdown перед коммитом проверьте preview или тесты документации, если проект использует пробельные hard line breaks. В CommonMark более заметная альтернатива — обратный слеш перед переводом строки. После такой миграции включённый `files.trimTrailingWhitespace` помогает удерживать репозиторий чистым без регулярных массовых cleanup-коммитов.

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

Как внедрить очистку без шумного коммита

В существующем проекте сначала включите trimming только для себя и несколько дней наблюдайте, какие файлы реально меняются при обычной работе. Если сохранение старого файла превращает небольшую правку в десятки удалённых пробелов, отделите такую очистку от функционального коммита или временно сузьте настройку по языку. Для документации проверьте Markdown preview, потому что пробелы могут участвовать в явном переносе строки. Когда команда согласует правило, закрепите его общей workspace-конфигурацией и проверкой репозитория. Такой переход даёт чистые новые изменения, но не заставляет одномоментно переписывать весь архивный код.

Проверка настройки

• Trailing spaces исчезают после Save в обычном исходном файле.
• Markdown-исключение работает там, где пробелы значимы.
• Auto Save не создаёт неожиданный большой diff.
• Formatter on save не смешан с тестом trimming.
• Командные правила при необходимости подтверждаются линтером/CI.

Что учитывать

Если после сохранения меняется не только конец строк, но и кавычки, запятые, переносы, indentation или порядок импортов, это уже работа formatter/code actions, а не `files.trimTrailingWhitespace`. Для прозрачной настройки отделите эти механизмы: сначала включите trimming и проверьте минимальный diff, затем отдельно решайте, нужен ли formatOnSave. Это особенно важно в старом проекте, где полный formatter может переписать тысячи строк. Команда Trim Trailing Whitespace существует и как ручное…

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Markdown and Visual Studio Code). Пример и формулировки — редакция N1RO на 2026-09-20.

• Markdown and Visual Studio Code
• Basic editing
• User and workspace settings
• CommonMark Spec — Hard line breaks