On naming files

My file-naming convention has evolved over a number of years. There’s nothing particularly complicated about it, but I’ve learned the hard way that changing it should be done cautiously. The goal was for it to be powerful enough without becoming a major chore.

The system started with something like:

230816-FILENAME.EXTENSION

This then changed to:

20230816-FILENAME.EXTENSION

because I felt it was clearer to others if the file started with the full year. Eventually, I decided I was not so fond of the aesthetics of unseparated dates, and that losing three character spaces was not so important, so the convention changed to:

2023-08-16-FILENAME.EXTENSION

I’ve been happy with this solution for a decade or longer.

Recently, reading through the Denote manual, I came across the `file-naming scheme’ section, which establishes the following convention:

20230816T143254==SIGNATURE--FILENAME__KEYWORDS.EXTENSION

Protesilaos’s explanation is convincing. It’s a thoughtful system and I’ve been considering adopting it. I like most things about it, but I’m on the fence about recording the time to the closest second. This is partly because I usually don’t have a second counting clock handy, and because on a personal level, it is rare that I would ever save a file more than once a minute. I’m afraid to end up either with invented second counts, double-zero second counts, or having to add the second counter to my taskbar time, which would be a constant distraction and (if I remember correctly, because it’s been years since I fidgeted with it), it would require Polybar to run the time script which updates the clock much more often as well.

I’m also reluctant to let go of the dashes that separate my year, month and day convention, because I like how easy it is to read the date with those separators. I understand that, given the scheme described by denote, those dashes would make anchoring for search confusing.

Also, on a personal level, I like to have spaces for some file and folder types, such as music. I acknowledge that dashes and underscores are good for most other purposes, and in the rare occasions when I have to operate on files with spaces on the command line, I dislike it.

Now, and perhaps more importantly, I’ve also been thinking of adopting this scheme for my business. This is more stressful, because once I release an SOP, it will affect everyone’s workflow. For business, it makes more sense to name files with the second counter on the date, as it is much more likely that two people might save a file during the same minute; the second counter would ensure a unique identifier in those cases. However, do we really need to make sure that there is a unique date identifier, or can we live with the imperfection of having two files with the same date identifier, but with different filenames? Will this ever affect us negatively? I think it’s doubtful.

I’m leaning towards removing the second counter and implementing the rest of Denote’s file-naming scheme. As a final note, I’m also not very happy about the aesthetics of double dashes, underscores or equal signs.

2023-08-23-project-x-proposal.pdf

vs.

20230823T143254--project-x-proposal__customery_proposals.pdf

vs. maybe

20230823T1432--project-x-proposal.pdf

I still lean toward the relative simplicity of my original, though I can see the advantages of Denote’s.

For the record, I don’t use Denote, and it probably makes a lot of sense to implement the full scheme when the program automatically inserts the full date-time identifier for the user.

For my purposes though, the jury’s still out.