Кратко: «чистые», предсказуемые, кроссплатформенные имена

Ниже — набор практических правил, которые реально работают в командах и не ломаются на разных ОС и инструментах.

Базовые правила

• Используйте только латиницу a–z, цифры 0–9, дефис - и подчёркивание _.
  Избегайте пробелов, акцентов/диакритики, эмодзи и экзотических символов.

• Не начинайте имя с точки . (в Unix это «скрытый» файл), дефиса или подчёркивания — начинайте с буквы.

• Длина: до 50–100 символов для читабельности; жёстный потолок у большинства ФС — 255 байт на имя и ~260 на путь в старом Windows.

• Регистр: придерживайтесь одного стиля (рекомендую snake_case или kebab-case), не смешивайте ReportFinalFINAL.docx.

• Не ставьте точку в конце имени и не делайте несколько точек подряд (..) — это ломает инструменты.

• Расширение — всегда в конце и строчными: report.pdf, а не Report.PDF.

Кроссплатформенность (Windows/macOS/Linux)

• Запрещённые символы (Windows): \ / : * ? " < > | и запрет на пробел/точку в конце имени.

• Зарезервированные имена (Windows): CON, PRN, AUX, NUL, COM1–COM9, LPT1–LPT9 — не используйте их вообще.

• Unix/Linux: нельзя / и нулевой байт.

• macOS: исторически нормализация Unicode может отличаться; чтобы избежать сюрпризов — используйте ASCII.

• Итог: если имя валидно в Windows, оно почти наверняка валидно везде.

Семантика и структура

Делайте имя самодокументируемым: что это, для кого, по какому контексту.

• Шаблон:
  произведение_назначение_контекст_дата_версия.расширение

• Примеры:
  invoice_acme_q3_2025-10-21_v02.pdf
ml_model_fraud_v1.3.0.pkl
design-system_buttons_specs_2025-09-15.md

Даты и время

• Формат ISO 8601: YYYY-MM-DD или, для сортировки по времени, YYYY-MM-DDThhmm (без двоеточий для совместимости):
  2025-10-21 или 2025-10-21T0930.

• Не используйте локальные форматы (21.10.25, 10-21-25) — они путают людей и сортировку.

Версионирование

• Явная метка версии: v01, v02… с ведущими нулями для правильной сортировки.

• Для артефактов ПО — SemVer: v1.3.0.

• Не используйте «final», «new», «latest» — вместо этого повышайте номер: ..._v07.

Нумерация и порядок

• Всегда нуль-паддинг: 001, 002, ... 010.

• Для серий: project_photos_001.jpg … project_photos_120.jpg — так корректно сортируется в проводниках и на серверах.

Разделители и стиль

• Предпочтительно: snake_case (monthly_report_2025-10-21_v03.pdf) или kebab-case (monthly-report-2025-10-21-v03.pdf).

• Избегайте пробелов: они создают экранирование в скриптах и URL.

Конфиденциальность и безопасность

• Не включайте персональные данные, секреты, ключи, токены, номера карт.

• Если требуется идентификатор — используйте внутренний код или хеш (user_7f9a2c), а не ФИО/телефон.

Устойчивость к автоматизации

• Стабильный шаблон имени облегчает парсинг скриптами: фиксированный порядок полей и разделители.

• Не меняйте схему именования «на лету» — внедряйте через README/CONTRIBUTING и линтеры в CI.

Что ещё учитывать

• Уникальность в каталоге: именуйте так, чтобы коллизии маловероятны (projA_... vs projB_...).

• Локаль: используйте английские слова для командной работы между языковыми группами.

• Не полагайтесь на регистр для различения: Report.pdf и report.pdf совпадут на Windows.

Плохие и хорошие примеры

Плохо:

• Новый файл (копия) (2).docx

• Отчёт 21.10.25 финал.docx

• budget:Q4*2025.xlsx

• CON.txt

• photo 1.jpg, photo 10.jpg (ломает сортировку)

Хорошо:

• budget_q4_2025-10-21_v04.xlsx

• marketing-plan_emea_2025_v1.0.pdf

• photos_site-visit_2025-09-01_001.jpg

• api_contract_orders_v2.1.0.yaml

Мини-чеклист перед сохранением

1. Только a–z 0–9 - _ и одна точка перед расширением.

2. Есть контекст (что/для кого), дата в ISO, версия.

3. Цифры и версии — с ведущими нулями.

4. Имя короче 100 символов и понятно без открытия файла.

5. Проходит «Windows-тест» (нет запрещённых символов/имен).