How to develop a naming convention
NAMING (CODING)
CONVENTION:
One of the main problems of not having a proper naming
convention is that if a file gets misfiled it is pretty much lost or it might
take a long time to find. For this reason the naming convention needs to
fulfill two things:
1.
A person must be able to determine where the file
belongs just by seeing the name of the file, so if the file is misplaced it
will be easy to spot. Also if you were to remove the folder structure the
file’s name would still follow the folder convention so it could be classified
without the use of folders.
2.
It must make it easy to determine what the file is just
by seeing the name of the file. This would also be beneficial for searches with
the search box as it would bring back all related files.
For this reason the naming convention will follow the folder
structure and also determine what it is. We will be using an alpha numeric code
that could be supported by ASCII so we will avoid the use of special characters
unsupported by ASCII.
First Initials determine the project the file belongs to:
-
Project 1 = P1
- Project 2 = P2
- Project 3 = P3
Second will be either an R for Raw or a E for Edited, this will
indicate whether the material is source material or not.
Third will be the type of material according to this:
Video: V
Photographs: P
Graphics: G
Audio: A
Artwork: ART
Marketing: M
These three elements conform the prefix.
For example, edited artwork from the Project 1 would have the
following prefix:
P1_EART
Project 3 raw video would be like this:
P3_RV
The next element should indicate the subproject it belongs to.
This means that each project, task or assignment would need to be named.
P3_RV_SUBPROJECT
If it were an
audio file it would be:
P3_RA_SUBPROJECT
Graphics:
P3_RG_SUBPROJECT
This would allow for a search in the finder to bring back all related assets quickly.
Any other information that is relevant would also follow here.
So, if a country is relevant then the country name would follow:
P3_EV_SUBPROJECT_SPAIN
For elements such as photographs, where there is an author that
might need to be identified, we would then add the name of the photographer. So
for example something like this:
P3_RP_SUBPROJECT_PhotographersName
The next element in the naming convention would be the date, if
applicable or relevant. The date will follow this format: YYYYP3DD
If the day was unknown or the month, then it would be YYYYP3 or
YYYY
So, an example would be:
P3_RP_SUBPROJECT_PhotographersName_20161022
Which would mean that this is a Project 3 raw
photograph concerning a sub project and shot by Photographers Name on the
22nd of October of 2016.
The next element would be an alphanumeric code, whether it has
already been created by the camera for example or if applicable it might be
created. For all legacy material, we would be using the filename that already
exists.
For material where there are several versions of the same
material, we would add a suffix that would consist of a “V” for Version and the
number. So for example V03 for a third version of something.
For video files we must add at the end:
FPS(frame rate)_AspectRatio_Version(Texted or textless)
It is important to keep in mind that each asset must have a
unique code in order to prevent the overwriting of files but that strands of
the code coincide for files that are the same thing, this is especially true
for edited files as raw files will generally tend to be unique.
The naming convention above all must be consistent throughout.
Comments
Post a Comment