It's just a standard that works. It's so drilled into my head that I use it for every single file on my computer.
Naming conventions are extremely important in an involved project or pipeline that might have 1000s of files and dozens or even 100s of team members. It's easy to understand and helps visually break an asset file name down. For example, a UE4 standard is to put M_ before all materials, or SM_ before all static meshes. This makes it easy to identify asset groups in a large project or scene. SM_small_tree works visually for several reasons, whereas smsmalltree hurts the brain.
Similarly with texture maps TX_small_tree_normal is so easy to read. txsmalltreenormal.......not so much.
Of course, none of these are rules, just good practice. Many artists just use hfdhfdjbt6 names in personal projects, but would never get away with it in a pipeline(and it is TERRIBLE practice if handing off assets to a client)
As above, but it’s also mostly a hangover from when you couldn’t have spaces in filenames. That said, anyone who does now use spaces in filenames should be shunned and sent to a special hut until they stop. It’s weird
Because spaces are source of confusion and they're a pain to deal with in programming/scripting like any special character. No spaces in an URL address for instance...Some software might not recognize them properly, so on...
So dashes, points or underscores... is a general convention for file naming (not only in 3d).
In the past it might've been for technical reasons, but now it's probably just a convention.
File systems support unicode filenames, they can certainly forgive the use of spaces. For command-line tools, you can enclose in quotes any paths that have spaces.
Any name with a space in it doesn't actually have a space when it's stored in memory. Instead in windows something like this:
desk chair.jpg
actually is:
desk%20c~.jpg
This is because really most operating systems are MS-Dos based (windows, xbox) or unix based (linux, playstation, maya). And neither system actually stores the names with spaces and instead it does weird stuff behind the scenes.
And it isn't arbitrary. Snake case allows you to differentiate between var, _var, var_, and _var_ when searching for things in your asset manager, which makes maintaining a prefix/suffix system a lot easier. It's uglier, and it can be harder to read at times, but it's more forgiving when you're trying to find things before your coffee kicks in.
CamelCase is still my go-to outside of asset management situations, though.
Using spaces in file names is in general VERY BAD IDEA if you work in multimedia industry. Underscore enables clean visual separation of negative space in text and if you like you can sometime even use file name as ad-hoc mini config to store values and parse them very quickly. The sooner you stick with it the better your life will be. Your potential future coworkers will for sure appreciate this!
Yeah, it's not just an old thing, even now spaces are kind of a special case character that'll get you in trouble in most scripting languages and operating systems due to their tendency to break folder links, not to mention there's actually a bunch of different characters that look like spaces but aren't, further adding to the confusion.
Some engines are super strict. I can't remember the exact reasons, but our last game engine would break during the building stage if we didn't export art using all lower case naming. To make things easier to read, we just separated words using underscores. (spaces were not allowed, because they'd also break the build)
Yeah the above and I think in the old days PC disk recovery depended on no caps and twas allowed to separate using the underscore. Anyhow there are enough situation where it works, so use it for everything.
+1 to @radiancef0rge Spaces in filenames or paths are an absolute bane for tech artists and engineers. We often times are reading directory paths and files from .csv, .txt, .ini, and a million other places. We will use end of line, carriage returns, and whitespaces to determine separation of file names, paths, objects and other things (not only in reading from file, but in dealing with data from various locations). This is one of the reason's dealing with "My Documents" ,"Program Files", and "Program Files (x86), can catch you off guard and be a real pain in the ass. Your code will be running along swimmingly and then you get a break because your code split up a path into "c:\users\My" and "Documents\Blah" instead of the whole path together. It's easy enough to resolve, but it's just one more thing to have to compensate for and never fun to encounter.
It was also said above that many applications don't allow spaces, and automatically convert to "_" to ensure the underlying code is never getting surprised by a rogue space.
I have also seen version control applications like Perforce automatically reformat filenames to lower case from camelCase when migrating servers...which then caused all python modules to fail on their imports because python is case sensitive.
The morale of the story is...IMO: your *safest* bet is lowercase separated by underscores, but as @Mark Dygert notes below, the readability of camelCase should not be understated.
A succinct explanation which I hope clarifies for the OP **WHY** the necessity for underscores, especially when as creative's we do by and large 'inhabit' digital space via doodling our creations, so at the end of the day forestall 'rogue space' by following convention:
its odd to me only 1 person has mentioned programming languages dont like spaces.
they don't like spaces for the same reason file systems don't like spaces - it all goes into memory and spaces are...
...wasted space.
In general I've found Python programmers like underscores and C-style languages (csharp, C++, mel) tend to use camelCase.
An interesting note you bring up regarding Python and C based languages. I've seen the same thing, particularly with Autodesk code. 99% of all Mel scripts and even their python code utilizes camelCase for variables and functions. What's interesting is that this is counter to PEP8 guidelines (no camelCase for either, only classes...IIRC). https://www.python.org/dev/peps/pep-0008/
For years and years I utilized camelCase in all of my code, as I followed convention with all of the other code (typically Mel) that I was learning from. However, I've recently changed that behavior to much more strict PEP8 compliance (no camelCase for variable or function names (PEP N802 I think it is). The reason I made this switch was because a very senior engineer advised me that in order to utilize a linter (an application that performs automated code inspections), it was best to adhere to strict PEP8 compliance. This ensures consistency across all co-developed code and automated code inspection. I suppose you could create exceptions for your linter...but that might be a slippery slope.
This is certainly something that I'm sure is very debatable among tech artists and engineers, but in a very large production environment I have discovered that it is useful in maintaining quality standards.
If you use an IDE like PyCharm it has automatic PEP8 code inspections built in which makes compliance easy.
I'm just throwing my 2 cents in behind CamelCase with the occasional underscore, if they let you. It really helps to check with your programming team and work out a convention early on. They usually have a very specific standard that they adhere to and generally would be pretty happy if you stuck to it. Or they will work with you to come up with some kind of exception and work around that helps create content. Being able to parse large volumes of content and sort it by specific characters can be pretty helpful.
Just replacing spaces with underscores can make for some really long, hard to read, file names. With CamelCase can be much more readable if you structure it with underscores: Weapon Action Description
MaceShield_AttackFwd_Light01 vs mace_shield_attack_fwd_light_01
The upper example, can allow you to use the underscores to parse the text by sections. Which can be very helpful if you're working within some kind of class hierarchy, it can also help sort files when they are displayed in long lists.
The lower example reads like a run on paragraph written by someone who doesn't understand punctuation. The sections are there but you need some higher level brain function constantly running telling you which word belongs in which section. The chances of it getting confused somewhere by someone is pretty great.
That is just 3 sections, it can get even more convoluted with environment art: EnviromentLocation BuildingSet ConstructionMaterial PartDescription VariationDescription
AlpineForest_WattleDaub_WoodPlaster_WallCorner_BrokenWoodenPillar01 vs Alpine_forest_wattle_and_daub_wood_and_plaster_wall_corner_broken_wooden_pillar_01
It's just easier to read and less prone to create mistakes and rework.
For anyone thinking that they can use spaces, good luck with that. It's not something we stick to because we're old and stuck in our ways, we would quickly change over if it wouldn't cause issues. Having a little bit of experience doesn't automatically make you brain dead =P
If you try to use spaces, you will run into a lot of issues really quickly. Some software treats them fine but others will have issues. If not in your DCC then as soon as you start working within an engine or with programmers. I hope it isn't in the form of some horrifically obscure bug that makes it really hard to track down. Usually you end up with something making a call to a truncated file name and it's clear as a bell what is happening. Another time you might get some very bazaar errors that don't make much sense and end up wasting a bunch of time tracking down the source of the issue. After 3hrs of digging "Oh look its because the new guy has been using spaces. Great! Well, guess who gets to spend the weekend cleaning up that mess? 1,2,3 not it." See you on Monday!
Either way, if you don't agree on a "cross-discipline naming convention", it will cause someone to go back and rename everything. Which breaks a bunch of links that have to be fixed in various ways.
Nothing gets a good naming convention burned into your brain like spending the day renaming files, fixing redirects and fixing broken references. It gets 10x worse when you add version control software like perforce or git that does not like bulk renaming. But hey, it's an important lesson to learn, some people can only learn it through negative reinforcement...
Replies
https://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2019/ENU/Maya-Customizing/files/GUID-2D9A00AB-05FD-486B-A510-22C7F02FC5DE-htm.html
Same with Houdini
File systems support unicode filenames, they can certainly forgive the use of spaces. For command-line tools, you can enclose in quotes any paths that have spaces.
desk chair.jpg
actually is:
desk%20c~.jpg
This is because really most operating systems are MS-Dos based (windows, xbox) or unix based (linux, playstation, maya). And neither system actually stores the names with spaces and instead it does weird stuff behind the scenes.
Also,...
younger people have shit grammar
CamelCase is still my go-to outside of asset management situations, though.
...wasted space.
In general I've found Python programmers like underscores and C-style languages (csharp, C++, mel) tend to use camelCase.
Spaces in filenames or paths are an absolute bane for tech artists and engineers. We often times are reading directory paths and files from .csv, .txt, .ini, and a million other places. We will use end of line, carriage returns, and whitespaces to determine separation of file names, paths, objects and other things (not only in reading from file, but in dealing with data from various locations). This is one of the reason's dealing with "My Documents" ,"Program Files", and "Program Files (x86), can catch you off guard and be a real pain in the ass. Your code will be running along swimmingly and then you get a break because your code split up a path into "c:\users\My" and "Documents\Blah" instead of the whole path together. It's easy enough to resolve, but it's just one more thing to have to compensate for and never fun to encounter.
It was also said above that many applications don't allow spaces, and automatically convert to "_" to ensure the underlying code is never getting surprised by a rogue space.
I have also seen version control applications like Perforce automatically reformat filenames to lower case from camelCase when migrating servers...which then caused all python modules to fail on their imports because python is case sensitive.
The morale of the story is...IMO: your *safest* bet is lowercase separated by underscores, but as @Mark Dygert notes below, the readability of camelCase should not be understated.
+1 @TTools
A succinct explanation which I hope clarifies for the OP **WHY** the necessity for underscores, especially when as creative's we do by and large 'inhabit' digital space via doodling our creations, so at the end of the day forestall 'rogue space' by following convention:
period_end_string
Cheers.
https://www.python.org/dev/peps/pep-0008/
For years and years I utilized camelCase in all of my code, as I followed convention with all of the other code (typically Mel) that I was learning from. However, I've recently changed that behavior to much more strict PEP8 compliance (no camelCase for variable or function names (PEP N802 I think it is). The reason I made this switch was because a very senior engineer advised me that in order to utilize a linter (an application that performs automated code inspections), it was best to adhere to strict PEP8 compliance. This ensures consistency across all co-developed code and automated code inspection. I suppose you could create exceptions for your linter...but that might be a slippery slope.
This is certainly something that I'm sure is very debatable among tech artists and engineers, but in a very large production environment I have discovered that it is useful in maintaining quality standards.
If you use an IDE like PyCharm it has automatic PEP8 code inspections built in which makes compliance easy.
Just replacing spaces with underscores can make for some really long, hard to read, file names. With CamelCase can be much more readable if you structure it with underscores: Weapon Action Description
vs
mace_shield_attack_fwd_light_01
The lower example reads like a run on paragraph written by someone who doesn't understand punctuation. The sections are there but you need some higher level brain function constantly running telling you which word belongs in which section. The chances of it getting confused somewhere by someone is pretty great.
That is just 3 sections, it can get even more convoluted with environment art: EnviromentLocation BuildingSet ConstructionMaterial PartDescription VariationDescription
vs
Alpine_forest_wattle_and_daub_wood_and_plaster_wall_corner_broken_wooden_pillar_01
For anyone thinking that they can use spaces, good luck with that. It's not something we stick to because we're old and stuck in our ways, we would quickly change over if it wouldn't cause issues. Having a little bit of experience doesn't automatically make you brain dead =P
If you try to use spaces, you will run into a lot of issues really quickly. Some software treats them fine but others will have issues. If not in your DCC then as soon as you start working within an engine or with programmers. I hope it isn't in the form of some horrifically obscure bug that makes it really hard to track down. Usually you end up with something making a call to a truncated file name and it's clear as a bell what is happening. Another time you might get some very bazaar errors that don't make much sense and end up wasting a bunch of time tracking down the source of the issue. After 3hrs of digging "Oh look its because the new guy has been using spaces. Great! Well, guess who gets to spend the weekend cleaning up that mess? 1,2,3 not it." See you on Monday!
Either way, if you don't agree on a "cross-discipline naming convention", it will cause someone to go back and rename everything. Which breaks a bunch of links that have to be fixed in various ways.
Nothing gets a good naming convention burned into your brain like spending the day renaming files, fixing redirects and fixing broken references. It gets 10x worse when you add version control software like perforce or git that does not like bulk renaming. But hey, it's an important lesson to learn, some people can only learn it through negative reinforcement...