How to Name Files in a Technical Documentation Project

© 2011 Ugur Akinci
Naming files — it sounds like something easy to do, doesn’t it? But I know from experience: it can actually become a very complicated and tangled-up affair with productivity-killing consequences.
The root of the problem lies in the fact that the name should make sense not only for the creator, the technical writer, but for the Document Management system as well. This system can be something as simple as a common network drive accessed by other writers and end-users, something a little bit more sophisticated like a SourceSafe directory, or a full-fledged content and version management system like Agile.
The human users like NAMES that has as many words as possible, DESCRIBING the CONTENT of the file. For example: “Model_101_DoorLock_Configuration_Guide.pdf”.
Machines, on the other hand, love sequential, discreet, and numeric LABELS that points at a LOCATION or ATTRIBUTE (like directory address or ID number) rather than the CONTENT of the file. For example: “123_JNM_V1.pdf”.
The trick is to reconcile these two different demands in one compact formulation.
The solution I prefer answers both of these concerns.
Start with a MACHINE LABEL and then append it with some sort of CONTENT DESCRIPTION.
For example, here is a sample file name that I like:

786-ABC-V1_Voltage-Regulator-Guide.pdf

The UNDERSCORE character is a marker that tells me where the machine label ends and content description begins.
The first part tells me the file’s system label. The second part is for my own personal use. Without that part, “786-ABC-V1.pdf” would not tell me anything about “what this file is all about”, especially when I’m dealing with hundreds or thousands of project files.
What do you think about this system? Which naming template do you use? Feel free to share.