special-test_final_3a_preview_5b
Do you know filenames like this? Or even worse, do you still use them? I did too. But I learned how to avoid these ugly names that no one can decipher 5 minutes later. And in this two parts series — that got inspired by a topic covered on Lifehacker and 43 Folders — I will show you how you can get a clean working naming convention, too. Just read on. It will take less then 5 minutes — promise.
First I will show you what to look out for in naming files and in the seconds part I will show you an example of how we use this new gained information to create a consistent naming template that is production ready and proven to work, because I and my company used it successfully for years.
###What you should know — The Basics
The most important thing about our files is the content, right? And in a project we need to make different versions of that content so we can easily recover after a crash or go back to an earlier version — a version that maybe worked better or one that now fits better into the directors concept. How do we go about naming this content so we can easily see what we are dealing with?
- never ever use the word “final” for any file
- do not put too much information in the filename
- put much info in your filename
- number your files incrementally — always
- stick to your naming convention
###Never ever use the word “final” for any file
Well, plain and simple: never use the word “final” as an integral part of the filename. For the simple reason that it never will be the final version. And what do you do then? Name your file “final_final”? Or “more_final”? It just won’t work out, so just don’t do it. Simple isn’t it?
Oh and while we are at it, try not to use these words either:
- temp
- test
- preview
###Do not put too much information in the filename
I don’t know about you, but when I want to read a story, I read a book. But when I am working I need to know which file is containing what — fast. That means the filename should only contain what is necessary to communicate its content. Nothing more. But most importantly nothing less, which leads us to the next point.
###Put much information in your filename
Well, as I wrote above, when you look at a file in your file-browser you need to see instantly — without opening the file — what it contains. For that you need to put all the important info into the filename.
But what is important you ask? Well, that certainly depends to a degree on your working environment and projects. A few things stay the same nevertheless. Lets make a small list. We normally need to know:
- what project this file belongs to
- what the file contains
- who created the file (in a multi-user workspace)
- which version it is
- what changed to the version before it
- when it was created
There you have it. Not an awful lot, isn’t it? To see how we squeeze all that info in a short and readable filename read on.
There are two ways to tackle this. One is to use shortcuts like the first letters of your project (MIB = Men in Black), the other one is to use plain readable text. Both have their advantages and disadvantages.
Shortcuts make filenames shorter and for the duration of the project probably also more readable (because you can see more of the information in a filename at once). On the other hand it will be probably pretty hard to decipher what a filename was meant to mean after a month or two when you have to revisit a project.
I tend to use a mix of both to get something as descriptive but short as possible.
###Number your files incrementally — always
This is also an important one. Always number your files starting with 01, not 1, but 01, because you never know, it might end up being the first of many drafts before the final — or, to stay consistent with our rule about not using the word “final” — the version that we end up using. So to avoid ugly constructs like version 2b5-new, we just stick to simple numbers 01, 02, 03 and so on. The recent version wasn’t good? No problem, make a new one and increase the version count. That leaves you with room for up to 99 versions, enough for even the most error and revision prone projects.
###Stick to your naming convention
Well, this seems to be obvious, but it isn’t very easy, especially in a working environment that has no rules about files names. Co-workers don’t use it, so why should you? To stay on top of the chaos and to lead by example. Once your co-workers see how easy and efficient a working naming convention can be they hopefully will switch to it, too.
I hope this was some useful info and if you wan to find out how we transfer this knowledge into a real life naming convention, then come back next week when I show you how I tend to use it.
Also please let me know what you think about this topic in the comments. Until then, take your work to the next level.