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

Popular posts from this blog

Key Takeaways from The Comic Toolbox by John Vorhaus

Finnish Language - Lesson 27: KPT changes

Finnish Language - Lesson 49: Monikon Partitiivi