As far as I know there are these;
- Camel case = coolFileName
- Snake case = cool_file_name
- Kebab case = cool-file-name
- Pascal case = CoolFileName
- Dot notation = cool.file.name
- Flat case = coolfilename
- Screaming case = COOLFILENAME
Personally I prefer the kebab/dot conventions simply because they allow for easy “navigation” with (ctrl+arrow keys) between each part. What are your preferences when it comes to this? Did I miss any schemes?
IWRITELOTSOFBASH
deleted by creator
I like to use my enterprise number and a UUID (all in lower case, for legibility). Here’s an example:
.1.3.6.1.4.1.33230.0d456e46-67e6-11ef-9c92-7b175b3ab1f1
Now you might say that the UUID is already globally unique or at least pretty unlikely to turn up anywhere else, so why bother prefixing it with more stuff? To that I say: “I need to be absolutely or at least reasonably sure … OK nearly sure”.
Anyway, you maintain a database of these things and then attach documentation and meaning to them. An editor could abstract and hide that away.
I started this post as a joke. Not sure anymore. Why get your knickers in a twist with naming conventions for variables and constants. Programming is already a whopping layer of abstraction from what the logic gates are up to, another one wont hurt!
General purpose: Kebab case
But really, follow the conventions of what you’re working on. For example, I’d use pascal case when working on a Java/Kotlin project, and snake case when working on a Python project.
My file
I try to make everything Pascal case. It’s easy to read in a terminal and pretty easy to type.
Kebab for most things, camel for source code
Snake case and kebab case mixed arbitrarily.
It really depends.
If I know I will never open the file in the terminal or batch process it in someways, I will name it using Common Case: “Cool Filename.odt”.
Anything besides that, snake case. Preferably prefixed with current date: “20240901_cool_filename”
CaN’t BeLiVe No OnE eLsE uSeS mOrOn ScRiPt FoR eVeRyThInG!
I ScRoLlEd ThIs FaR fOr SpOnGeBoB cAsE
Underscore to delineate different parts, hypen to delineate words.
Like: my-resume_draft.pdf
And to make it consistent and easier to reuse parts for project names and such, I have a command line utility written for it. It caches the parts and uses a template system (support for generating current datetime in parts)
Available here (is in AUR too):
You can go-to_hell.
Thats what I do as well. It makes it easy to seperate between logical units.
Kebab case with Pascal case in the usual places. I’d change to all kebab case but the muscle memory of typing Documents would nearly kill me.
I don’t have a consistent style for everything and it depends on the circumstances. snake_case is often used, especially to avoid spaces. Sometimes I just do flatcase instead, and in rare cases also kebab-case or combined_snake-and-kebab-case. The combined_case is often useful to group parts of the name, like a dates and version numbers together and to indicate what part is constant; example-name_2024-08. Sometimes I also do the “Title Case”, which is basically PascalCase, but with spaces. Or even even more weird, “Python_Case”, which is PascalCase, but with snake_case, when I want to avoid spaces.
I often avoid dots in regular filenames, unless they indicate a file extension or format, such as “.svg” and “.inkscape.svg” to indicate its a specific version of the SVG format. Or “.xiso.iso”, as a specific compressed version of the regular ISO file (for use with Xemu emulator). Basically the same logic and tradition as “.tar.gz” (but in reverse order).
I don’t like extra dots simply because pattern matching might get weird down the road. Keep dots for extension type and use Pascal to make it easier to read multiple words. Flatcase only if it’s short or I’m lazy for a temp file.
If its my own personal code, snake case, if I am sharing with my frontend devs then camel case. If I am writing short scripts, then flat.
Snake case, but I’m the World’s second worst programmer and just name files like this because I was alive when spaces were not allowed.