Alexander Kucera

Follow @AlexKucera on

Naming Conventions - Part 02 - Real Life Application

Last time I talked about the basic ingredients of a working naming convention, which got inspired by a topic covered on Lifehacker and 43 Folders. What to avoid — like never using the word “final” in any circumstances — and what to include — for example version numbers.

This time I will show you how to use this new gained knowledge and plug its elements together into a working template for a professional naming convention. Just read on to find out how it’s done.

###The Template

Actually it is very simple. Take what we have spoken about last time and plug the elements together to get a working naming convention, like this (this might wrap a bit unlucky, if so just wait till we get to the real life example — which reads more easily — two lines further down):

<project-name>_<file-content>_<version-number>_<changes to the version before>_<author>.<file-extension>

Easy, isn’t it? So in a more lifelike example we get:

This file is part of the project called “The Ambulance” and it contains the greenscreen keying and compositing for shot 012 and is in it’s third revision. The change to the last version is a fix in one of the masks (which probably was wrong in version 02) and the change was done by me.

###It sorts in groups…

As you can see this is a pretty human-readable filename. And just from looking at it we can see what is going on. And because of the way we built the filename it sorts correctly when we sort by filename in the file-browser. We will always see the shots for the project “ambul” together, followed by all versions of keying shots, then the individual shots in order and then the individual versions of a shot.

And if you ever accidentally save your file in the wrong folder(another project or your local drive instead of the projects drive), it becomes pretty easy to find again, because it includes the project name.

###…and is extensible

The nice thing about this order is that we can now add as many additional informations to the filename as we deem necessary after the version number — like in this case the changes to the last version and the authors name. We will always get it sorted in the right way, because the version number comes first in the filename.

And we also need not worry about including the date in the filename directly in most cases, because the operating system takes care of this automatically.

There is not one correct way — the template adjusts to your taste

There are of course many different options to express the same information as above. We could also write any of the following:

  • the ambulance_keyingShot012_
  • ambul-keying shot 012-v03-fixed mask

All these versions contain the same info. Some are more verbose, others less. Some are easier to read, others less. I tend to stick with underscores to divide the individual chunks of information and dashes or a combination of small and capital letters to make the individual chunks more readable. This comes from my programming history. If other schemes are easier to read for you, take them instead. This part is completely up to your taste and doesn’t influence the effectiveness of this naming convention as long as you always use the same method.

###Do yourself a favor — stick to it

Stick to it once you have a working naming convention. And please don’t try to change it after every project. You will be thankful for sticking with it when that project resurfaces after a month or a year.

If you have questions or suggestions about my way of naming files please leave a comment. I’d love to read about your ways of tackling this issue.