Hello everybody,

I was wondering what types of naming conventions do you use in your projects (if any)? Do names get very specific (you can read the name and know exactly what it is)? Or do you use shorter, codified names for your files (textures, models, code)?

Hi! After years of programming I never found a satifying naming convention :). Always searching. Actually I'm programming in c++ and I'm using long and quite specific names for class members and private methods, while trying to keep public method names very short. In this way I'm trying to have a class whose internals are easy to read (in the case I return on the code after a while) and keep the code short when use the class. I found c++ is already a lot due namespaces, iterators, templates and stuff like that.

Filenaming conventions should be project-specific for project-specific files. You may need a different convention for a different project. You want all filenames to be meaningful to the team. In the past, we used an identifying letter or 2 in the filename to specify whether the file is related to a specific character or location. We used a character to specify the asset type. We used 3 to 4 digits for identifying the asset, and had an Excel table to identify the asset, but that wasn't the best way to go when there were a lot of assets. You can use a few more letters to further identify the asset specifically.

Naming has an element of good taste that is hard to codify into concrete rules. I don't use abbreviations (because "Com" might obviously mean "communication" to you today, but it could also mean "common" or "compute" or something else, and figuring this out is extra effort that nobody needs), and I try to use names that are descriptive enough that the reader won't be surprised when reading the code in more detail, but I don't try to reproduce every detail of the algorithms in the names.

Tomato Head said:
(textures, models, code)

Depends on the code base, but yes, most develop standards.

Code is usually easily distinguished by file extensions, then by path or descriptive names.

It can be tricky when dealing with engines like Unreal or Unity, where all game assets get the same extension. There, common prefixes like T_ for Texture, M_ for Mesh or Material, and names for what they're in, perhaps FE_ for frontend, or MapZone_Thing like Beach4_Spawners.

Ultimately it's all up each project, each one does things differently.

Giving my two cents: I'm searching for the past 6 years of a good naming convention, especially because I'm writing code depending on my daily constitution so I'm the one person that has to be guided most (by my own, sounds a little bit schizo). I code mostly in C# standard notation because I really dislike writing all in lower case with underscores as for example the C++ STL does. No prefixes, no underscroe, just meaningful naming.

There is a file on my GitHub I wrote some time ago.

For the project structure, this is getting more difficult and changes from time to time while refactoring. First of all I like to categorize everything and because of the modular way I develop my projects, there are always directories that contain atomic proposals. For example Math or Input while "generic" code is going into a Common module project. Everything however also has a Common folder because I don't like Misc or Utils/ Utility; this can be everything and nothing so I thought Common fits all these most. Every other directory in a project is named by a short, 99% of the time single worded and meaningful noun. This can be Math, Text or System for example but the remaining 1% can for example be ObjectModel. Naming code files is simple either done by their proposal, so Clang or Keywords or determined by their contained (main) class TreeBuilder, InputStream or CommandLineParser.

However there are some special exceptions to this rule: C# partial classes are named like their master file with the categorization of the kind of partial extension, separated by a dot while C++ header files that are supposed to be included by another header file in order to extend those are named with an additional .Partial before the extension and after the master file name. Same for RTTI extensions (generated by our C++ reflection tool) that are extended with .TypeInfo.

Our build tool Forge also relies on certain files being named properly. Any directory that contains a .Build.cs file is treated as plugin for Forge and so compiled and/or reloaded on startup while .Build.dva files define a PU used in the tools pipeline. Anything else .Whatever.dva is treated as Whatever-Module (Rendering or ECS for example) and compiled into code that special data driven pipeline host needs (the render pipeline for example is assembled from all .Render.dva definition files while .ECS.dva generates C++ System code)

While choosing identifiers in code is a big deal because they are meaningful, file names only need various concretely useful properties:

• hard to misspell if written by hand
• easily distinguishable (e.g. "1O0" vs. "l0O")
• consistent with each other
• corresponding to the file content (informally, e.g. descriptive titles for artwork, or exactly, like Java source files that have the same name as the class they contain)
• not changing randomly (e.g. preserving original names of imported assets)
• short and obfuscated
• containing human-friendly metadata (e.g. size in image file names: "kitchen-background-800-600.png")
• computable from simple rules (e.g. if the third frame of the "jump" animation of the "soldier" sprite is requested, attempt to load "soldier-jump-003.png"; it might be implied that if it doesn't exist the animation has less than 3 frames)

Of course, many such properties are incompatible, and many file names (e.g. source code files that are processed in build scripts by enumerating directory content rather than from an explicit list) don't really matter. What does your particular project need the most? What file types require more naming discipline?