A filename is a small interface

A file usually outlives the conversation that created it. “The latest export” is perfectly clear while two people are discussing it. A month later, a directory containing three files called export-new.csv is less helpful.

A good name gives the next reader a little of the missing context. It does not need to describe everything. It just needs to answer the first few questions.

Choose the useful pieces

For a small collection of recurring exports, a date, a subject, and the real file extension can be enough:

2026-10-01-reading-list.csv
2026-10-08-reading-list.csv
2026-10-15-reading-list.csv

With a consistent four-digit year and two-digit month and day, alphabetical ordering of those date prefixes follows calendar order. The subject distinguishes the collection from a different export made on the same day. The extension tells a reader what sort of file to expect.

Decide what the date means. Is it the export date or the date covered by the data? Either can work; quietly switching between them creates ambiguity. One sentence in a nearby README can settle the convention.

Keep the convention smaller than the work

A naming scheme is useful when people can apply it without consulting a long rulebook. Add a revision only when revisions genuinely need to coexist. Add a project label only when the directory no longer provides enough context.

Names are visible to file browsers, command output, attachments, and people who never saw the original project. Avoid putting confidential details in them. Renaming a sensitive document does not change the sensitivity of its contents, but it can avoid advertising those contents unnecessarily.

There is no universal perfect filename. The useful test is simpler: hand the file to someone without explaining it. If its name gives them a sensible first step, the interface is doing its job.