File naming conventions: the setup order that holds up

A file naming convention is usually presented as a template to copy. Date, then client, then document type, separated by underscores, and the problem is declared solved. Templates are easy to publish and they are also why so many conventions collapse within a quarter: the template arrives without the decisions behind it, so the first file that does not fit the shape gets named by improvisation, and improvisation spreads.

The decisions have a dependency order. What goes in the name depends on what is actually typed into a search box. The separator depends on whether a terminal is ever involved. How the counter is padded depends on where the list gets read. Taken in that order, each choice closes off a set of later problems. Taken out of order, the work gets redone.

Record what gets typed before deciding what gets written

The first step involves no files. For one week, write down the first word that comes to mind each time something has to be found. Not the search that eventually worked, the word that surfaced first.

Three categories cover almost everything: a client or counterparty, a period of time, or a kind of document. One of them will dominate, usually by a wide margin, and that one belongs at the front of the name. This is the only part of a naming convention that cannot be borrowed from someone else, because it reflects how a particular job is divided rather than how filing is supposed to work in general.

The distinction matters more than it sounds. A name beginning with a date produces a list clustered by month. A name beginning with a client produces a list clustered by client. Both are searchable, but only the leading field determines what the eye sees when a folder is opened, and a list clustered along the wrong axis means scanning vertically every single time. That scanning cost is invisible in any individual instance and substantial across a year.

The same week of notes should record the route as well as the word. Spotlight, a Finder window, or a terminal prompt. If the terminal appears at all, two later decisions change: spaces become expensive, and brackets become a nuisance. If it never appears, both constraints can be dropped and the names can be more readable.

Choose three fields, not seven

Every field added to a name is a field that has to be typed, decided on, and occasionally left blank. The realistic ceiling is three, with a fourth reserved for a version marker where revisions are routine.

The test for whether a field earns its place is simple: how many times a month does that field get typed as a search term. A project code that nobody remembers scores zero. An owner name in a one person operation scores zero. Anything scoring zero belongs in a folder or a tag, not in every filename from now until the end of the year.

Fields that survive this test tend to be the counterparty, the period, and the document type. What varies is their order, which the previous step already determined, and whether the period is the date on the document or the date it arrived. Those two diverge constantly. An invoice issued on the last day of a month often lands two days later, so a name built from the document date and a list sorted by modification time will disagree about which month it belongs to. Pick one, write it down, and the disagreement stops mattering.

Write three real examples once the fields are fixed. Abstract rules get reinterpreted; concrete examples do not.

Two separators doing two different jobs

A single separator character cannot express structure. Using one character between fields and a different one inside a field can.

The common allocation is an underscore between fields and a hyphen inside a field, which makes 2026-09-11_beta-corp_invoice.pdf decomposable without ambiguity. Three underscores means three fields, and the hyphens inside the second field are clearly part of a company name rather than a boundary. Anything that later needs to parse these names, whether a script or a person, gets an unambiguous split.

Spaces are the decision that depends on the terminal note from step one. In Finder alone they cost nothing and read better. At a shell prompt every space requires quoting, and a name containing one will eventually be passed unquoted into something that splits it into two arguments. Parentheses and ampersands carry the same cost for the same reason, and both are usually replaceable: a parenthetical note becomes another field with a fixed word in it.

Some characters are not available regardless of preference. Apple's documentation for renaming items states that numbers and most symbols are permitted, that a colon cannot be included, that a name cannot begin with a period, and that some apps will not accept a slash in a filename. The colon rule is the one that catches people writing a time into a name, which is why timestamps in filenames tend to appear as 1430 or 14-30.

Dates and counters decide what the sort order means

Two format choices determine whether a sorted list is meaningful or merely alphabetical.

The date format has to lead with the year. 2026-09-11 and 20260911 both sort chronologically as plain text, because the most significant component comes first. Any format leading with a day or a month sorts into nonsense, and a mixed folder where some names lead with the year and some do not sorts into nonsense twice over. Month and day both need two digits, since 2026-9-11 sorts after 2026-10-01 when compared character by character.

Counters need fixed width for the same reason, and the consequence is more visible than most people expect, because the Finder and the terminal do not agree on how to order numbers. The Finder compares numerically, so estimate 2.pdf precedes estimate 10.pdf. The ls command compares character by character, so estimate 10.pdf comes first. Neither is broken. Padding the counter to a fixed width makes both produce the same order, which matters to anyone who keeps the same folder open in two windows.

Format choice	Sorts chronologically as text	Same order in Finder and ls	Safe to pass unquoted at a shell prompt
2026-09-11_client_invoice.pdf	Yes	Yes	Yes
11-09-2026 client invoice.pdf	No	Yes	No
invoice 2.pdf, invoice 10.pdf	Not applicable	No	No
invoice_002.pdf, invoice_010.pdf	Not applicable	Yes	Yes

Version markers follow the same padding logic. Where a document is revised more than nine times, v01 avoids the reordering that v1 through v10 produces.

Decide what happens to the files that do not fit

The first crack in a convention appears the day a file has nothing to put in one of the fields. An internal memo with no counterparty. A scanned receipt with no legible date. A reference document that is not one of the recognised types.

Three things need deciding in advance, and all three take about a minute. Whether an empty field gets a fixed placeholder word or gets omitted entirely. Which folder holds the items that do not fit the convention at all. Which day of the month those items get revisited.

The placeholder approach keeps the field count constant, which means positional parsing continues to work and the names stay visually aligned in a list. Omitting the field keeps names shorter but makes the structure variable, so anything reading the names by position breaks. For a workflow with no scripting in it, omission is fine. For one where names get processed, placeholders pay off later.

Whatever is chosen goes into the same note as the rest of the convention. An exception rule held in memory is reinvented differently the second time it is needed, and a convention that gets reinvented is no longer a convention.

Applying the rule to files that already exist

Nothing here requires a full retrospective cleanup. The convention applies to new files from today, and old files get corrected only where a failed search has actually caused trouble. That usually means one or two folders.

For those folders, three routes exist, and they differ in what they can express.

Route	Reorders fields	Preview before applying	Undo	Comfortable at thousands of files
Finder Rename (Control click, Rename)	No	Partial	Yes, standard undo	Yes
Shell loop with mv	Yes	Only if run with echo first	No	Yes
Manual editing	Yes	Not applicable	Yes	No

Finder handles three operations: replacing text inside names, adding text before or after names, and applying a format with an index, a counter or a date. That covers normalising a company name across a folder, prefixing a batch, and renumbering a sequence. What it cannot do is move the date from the end of a name to the front, because reordering is not expressible as find and replace.

Reordering belongs in a shell loop, with two precautions. Run the loop with echo in front of the mv first, so the entire operation prints without touching anything and the output can be read for names that look wrong. Then run it with mv -n, which refuses to overwrite an existing file rather than replacing it silently. That second flag matters because normalising names can make two previously distinct files collide, and the default behaviour destroys one of them without a prompt.

One more constraint applies on a standard Mac volume, which is case insensitive by default. Renaming Report.txt to report.txt works, but Report.txt and report.txt cannot coexist as separate files. A convention that assigns meaning to capitalisation will not hold.

The check that keeps it alive

A convention decays quietly. The way to notice is to count, once a month, how many names in the working folders do not match the rule.

A handful means the rule is working and those files need fixing. Several dozen means something about the rule does not match the work, and the productive move is to look at what the non conforming names have in common rather than to correct them one at a time. Usually they share a document type that the field structure never accommodated, and the fix is a decision rather than a rename.

The other half of the monthly check is the exception folder from earlier. If it is empty, the rule covers the real workload. If it keeps growing, a field is missing.

What a naming convention cannot shorten is everything that happens after a file is found. Locating an invoice quickly does not help with copying its path into a terminal window, running a conversion, and switching back to check the result. That gap is structural rather than a naming problem, which is why counting both numbers during the first week is worth the effort: searches that failed, and window switches that followed successful searches. The second number is the one a comparison of file managers is relevant to, and the pricing page covers what the paid options cost. Names handle the first number and nothing else.

What to change first

Fix the date format before anything else, because it is the single decision that changes both sort order and search behaviour, and it costs nothing to adopt on the next file saved. Then spend one week recording first search words, since that determines field order and cannot be guessed. If the counting shows the delay is mostly in what happens after the file is found, the naming rule is not the bottleneck and Atriens addresses the part that is.