Как называть файлы

 Публичный пост
12 марта 2024  363
Долоры

Три года назад, я решила раз и навсегда решить проблему с десятками файлов с названием 11111111.txt и его вариациями.

Казалось бы, какая незначительная часть жизни - какие-то файлы и их названия. Но мне это доставляло очень много боли - мелкой зудящей боли. Тут тебе и микропереключения - вместо того, чтобы сфокусироваться на задаче, начинаешь искать файл и усиленно вспоминать где же нужная тебе информация. И потери на лишний этап обработки - чтобы понять содержимое, нужно его открыть. И неработающий должным образом интерфейс - из-за того, что название файла неинформативно и однозначно, взаимодействие либо нарушается, либо усложняется.

Итак, задачи:

  1. быстро находить нужный файл;
  2. по названию однозначно понимать его содержимое;
  3. имя файла должно работать как интерфейс - т.е. в названии должна быть минимальная, но при этом достаточная информация для взаимодействия между всеми участниками.

План: идем в интернет, там быстро находим существующий фреймворк, немного его адаптируем и внедряем.

Какого же было мое удивление, когда за два часа активного поиска я не нашла практически ничего о naming convention. То ли потому что, тема не секси, то ли потому, что это очень зависит от организации, то ли потому, что никто кроме меня не страдает от такой проблемы.

Однако, что-то там все-таки было.

Подход 1. Для последовательных

Данный подход от The University of British Columbia предлагает любое имя файла составлять из трех [или четырех, если документ имеет ревизию] элементов - универсального идентификатора (определяет контекст или проект), темы документа, даты и ревизии.

Пример: ProjectX_SalesReportQ3_20210805_Rev0

В большинстве случаев я использую именно этот метод, но с некоторыми изменениями:

  1. Универсальный идентификатор - это не только название проекта, или, скажем, клиент. Это может быть что угодно, что позволяет сгруппировать файлы по какому-либо признаку. Например, во всех личных документах я ставлю свои инициалы - EZ.
  2. В видео есть рекомендация избегать пробелов, т.к. это грозит проблемами с максимально допустимым именем файла и разрывом ссылки. Когда-то давно я сталкивалась с такими проблемами, но как будто бы сейчас они не очень актуальны. Зато актуальна быстрая читабельность. Я плохо переношу сплошной текст без пробелов, да и эстетически меня это бесит, поэтому если пробелы нужны, то я их оставляю.
  3. Похожая штука с нижним подчеркиванием - не переношу его визуально, поэтому заменяю его на дефис. Вкусовщина.
  4. Дату YYYY-MM-DD тоже разделяю дефисом, т.к. сложно читать сплошной текст.
  5. Считаю, что дата создания документа и ревизия взаимозаменяют друг друга, поэтому если у документа есть ревизия, то дата в названии не нужна.

В итоге, вот так будет выглядеть название моего резюме: EZ-CV Product Lead-2023-02-28

Подход 2. Для ленивых расслабленных

Этот метод из книги «Горшочек не вари», которая посвящена организации своего цифрового пространства. Схема, которую предлагает автор Марк Херст: инициалы-дата-тема.

Пример: EZ-0228-CV Product Lead

Три основные части, разделенные дефисом. Это похоже на схему из предыдущего подхода, поэтому давайте поговорим о различиях.

  1. Хотя сам Марк и говорит о важности разделения файлов по контексту и проектам, в его схеме отсутствует инструмент для этого. Инициалы автора могут работать для определенной группы файлов, но что если файл предполагает одновременную работу нескольких человек, или вообще автор не так важен. Вот пример из его же книги - как понять два документа с темой comments от некоего pt - это комментарии из одного и того же контекста, но с разной датой, или два совершенно независимых документа?

  1. Расположение даты перед темой тоже очень спорное решение, ведь в такой схеме дата становится более приоритетным критерием сортировки, чем тема. Т.е. если у вас есть два договора с одним и тем же клиентом, но разной датой, то в общем списке документов они будут расположены не рядом.
  2. За дефис - уважаем 😎

Однако, в книге есть еще одна глава, которая обратила на себя мое внимание - «Хранение фотографий». Там предлагается организовать двухуровневое хранение со следующей иерархией: [год] >> [месяц-событие]. И вот именно тут, в фотографиях, дата становится приоритетным критерием для сортировки.

Мне категорически не хотелось делать какие-то два уровня и потом бесконечно шариться из папки в папку. Поэтому весь имеющийся архив приобрел вот такой вид:

Подход 3. Для фаст энд фьюриос

Этот метод повстречался мне случайно - в статье как замайндмепить все. Идея в том, чтобы к названию файла [которое может быть произвольным] добавить префикс, позволяющий поиском очень быстро отфильтровать определенную группу файлов.

Скажем, среди сотни экселевских файлов на вашем компьютере у вас есть три, в которых вы ведете все домашние дела - считаете бюджет, записываете показания счетчиков и следите за сервисным обслуживанием вашего автомобиля. В имя этих файлов можно добавить префикс h. - и тогда в поиске вам достаточно напечатать два символа и перед вами будет список нужных вам документов. Лучше всего это работает со Spotlight на mac os и PowerToys Run на windows.

Расскажите, есть ли у вас свой подход к наименованию файлов и главное - как вы к нему пришли.

Аватар Катя Живутская
Катя Живутская @kodacaster
Jack of all tradesArrival
📍Leamington, Великобритания

Проектирую автомобили, развиваю хайкинг в России, думаю как инженер здесь → t.me/zhivutskaya

12 комментариев 👇

Все фалы по проекту храню в одной папке проекта. А папки проектов в отдельной папке "проекты". Вроде не было проблем с поиском. Но в названии стараюсь указать суть документа и какой-то идентификатор связи с проектом.

Мне первый подход понравился :)

  Развернуть 1 комментарий

Когда-нибудь я возьму отпуск на год и наведу порядок на всех хардах 🙃

  Развернуть 1 комментарий

@oleqa, Звучит как "никогда" )))

  Развернуть 1 комментарий

Мне кажется, что с распространением всяких там ноушенов и обсидианов проблема именования файлов уходит на задний план...

  Развернуть 1 комментарий

@cartmendum, да, есть такое

  Развернуть 1 комментарий

@cartmendum, поясните? сам пользую Google задачи и Miro

  Развернуть 1 комментарий

@kirill144, как часто вам надо было создавать файл и думать как его назвать?...
В miro, кстати, этот вопрос все еще актуален: как назвать новую доску, чтобы потом ее проще было найти

  Развернуть 1 комментарий

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

Ну и все проекты названы по определенному принципу (постараюсь описать свою экосистему в ближайшие дни). Главный элемент в названии проекта — айди, в котором «вшиты» идентификатор клиента и номер проекта. Выглядит это примерно так: A03.02 Blah-Blah Project. А03 — клиент, 02 — проект.

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

  Развернуть 1 комментарий

идентификатор клиента и номер проекта. Выглядит это примерно так: A03.02 Blah-Blah Project. А03 — клиент, 02 — проект.

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

Кстати, выглядит интересно и разумно.

  Развернуть 1 комментарий

Я использую UUID в качестве имен файлов и папок.

Вообще этот пост — частный случай хвале подходу bottom-up.

Имя файла, имя папки — это метадата для содержимого. Я всегда максимально оттягиваю момент выдачи заголовка чему-либо, потому что заголовок служит для обобщения смысла, а реальная ценность в содержимом. Озаглавить можно по-разному, но если нечего озаглавливать то и польза нулевая, так что вначале я стремлюсь выдать результат, а потом озаглавить. В большинстве случаев я либо скриптом генерирую UUID, либо это «fdsjfaklarlreaw».

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

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

Чтобы решить эту проблему, я использую bottom-up подход, плоскую структуру, фасетную классификацию, UUID-имена файлов и полностью полагаюсь на поиск.

Фасетную классификацию ставят в противовес наследованию. Допустим у меня есть папка C:\music\rammstein. Я могу поместить ее в каталог metal, а могу в rock, но не могу сразу в оба. А что если исполнитель работает в разных жанрах? Переместить в папку другое? Можно сделать ссылку, но при переносе файлов в другую локацию ссылки ломаются.

Вместо создания иерархии я помещаю папку в C:\куча\rammstein и докидываю внутрь файл, в имени которого нужные мне описательные теги (фасеты), которые встроены лично в моё мышление — мне не нужно воссоздавать всю придуманную иерархию описания творчества Rammstien, я добавляю только исходя из тех слов, которые использую при мышлении.
Файл называется: music rock metal rammstein.index

Рядом будет лежать C:\куча\age of empires и внутри описательный тег: games strategies age of empires.index

Все мои файлы просто лежат в C:\куча\ — т.е., плоская структура сущностей.


Внутри кажой папки — описательный файл.

Все мои заметки лежат в C:\куча\notes без какой-либо иерархии.

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

Мне больше не нужно думать (тратить мыслетопливо на рутину) по какому признаку сгруппировать папку в компьютере — я создаю описательный файл внутри папки исходя из текущих мыслей в моей голове.

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

Для windows есть замечательная программа Search Everything, которая на моих 1_200_000 файлах отрабатывает меньше чем за 10мс.

Вообще софт выстроен таким образом что не всегда идёт на пользу

  • Почтовый клиент - провоцирует написать заголовок
  • Заметочники - провоцируют написать заголовок (хотя материала может быть недостаточно)
  • Иерархия папок - провоцирует подобрать нужную папку
  • todo - позволяют создавать иерархию, обкладывать тегами
  • Excel провоцирует заполнять концептуальные пустоты на пересечении ячеек (иногда хорошо, иногда вредит)

Но речь не об этом. Заголовок в письме - это нормально, и заполнение пустот в Excel тоже чтобы обнаружить детали.

  • в твиттере, vk, instagram, facebook не зря нет заголовков — иначе бы больший процент пользователей отсеивался на придумывании заголовка
  • на бумаге у меня нет нужды писать заголовки
  • в мессенджерах я просто пишу что хочу сказать, я не спотыкаюсь об заголовок
  • в речи тоже часто мне не нужно придумывать заголовок, хотя и бывает что он озвучивается, например «Хочу обсудить с тобой поездку на Кавказ»

Минусы.

Без поисковой системы найти что-либо практически невозможно.

Бывает ситуация, поиск не даёт результата — в прошлый раз снабдил недостаточным количеством ключевых слов. В итоге через мучение всё-таки находишь нужный файл / заметку. В таких ситуациях я добавляю те слова, которые использовал при поиске в описательную часть (файл или текст заметки). Об такие кейсы мозг учится в следующий раз снабжать получше описание.

Плоская структура, фасетная классификацию, UUID-имена файлов и поиск

«Давать заголовки — тратит мыслетопливо, поэтому больно в мозг», потому что нужно удерживать в рабочей памяти соответствие заголовка и содержимого. Если ещё обобщить, то «Top-down подход — тратит мыслетопливо, потому что нужно подгонять содержимое (bottom) под верхнеуровневое описание (top).

Лучше экономить мыслетопливо для top-down задач срезая углы используя bottom-up там где это возможно. Плоская структура, фасетная классификацию, UUID-имена файлов и поиск — провоцируют больше использовать bottom-up подход, который существенно проще и поэтому помогает сэкономить мыслетопливо для тех мест где действительно приходится прикладывать ресурснозатратный top-down подход.

  Развернуть 1 комментарий

@ivan_kopylove, интересный подход. Захотелось потестировать, т.к. после прочтения появились вопросы, которые, возможно, отпадут после опробования.

В частности, заинтересовало в контексте того же Обсидиана и как там будет работать поиск.

  Развернуть 1 комментарий

@mirza,

Добавлю про Obsidian.

Я добрал необходимую функциональность плагинами. Получилось немного костыльно, зато работает и мне удобно. Плагины с большим количеством скачиваний и скорее всего поддержка данных плагинов будет продолжаться (по крайней мере Templater — это топ-4 из плагинов).


Плагин Templater с шаблоном — при создании файла через Quick Switcher (CTRL / CMD + O) автоматически назначает файлу случайный UUID и перемещает файл в подкаталог с UUID. Перемещение в подкаталог нужно чтобы все вложения, связанные с этой заметкой, были связаны физически одним каталогом (для группирования файлов по смыслу).


Плагин Front Matter Title для того чтобы вернуть функциональность отображения заголовков.

Шаблон Templater:

---
id: new note - template - personal
created: <% tp.date.now("YYYY-MM-DDTHH:mm:ss+0300") %>
aliases:
  - 
  - 
tags:
  - #
  - #
  - #
---

<%*
let newName = await tp.user.uuidv4()
await tp.file.move(tp.file.folder(true) + "/" + newName + "/" + newName)
-%>

uuidv4.js — кастомный скрипт для Templater, вынесен в файл, но можно и сгенерировать в коде, потому что под капотом выполняется весь Javascript-код.

function uuidv4() {
  return ([1e7]+-1e3+-4e3+-8e3+-1e11).replace(/[018]/g, c =>
    (c ^ crypto.getRandomValues(new Uint8Array(1))[0] & 15 >> c / 4).toString(16)
  );
}

module.exports = uuidv4;

Если будут какие-то вопросы, с удовольствием отвечу.

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб