A kebab, a camel, and Pascal walked into a codespace...
In contrast to what the title might indicate, this blog post is not the start of a joke. Instead of dad joking around, I want to talk about casing in naming in programming.
Only interested in the short version about how I name my stuff in programming? Skip to the conclusion. If you want to go for the full story, keep on reading. Let’s dive in. 😊
What do I mean with casing?
In programming, spaces are a kind of character that is reserved. You can’t use spaces in variables, so we replace the spacing with something that makes us able to still read it.
For example, if you declare a variable to indicate the visible item count:
visible item count = 5;
So we declare the variable like this:
visibleItemCount - 5;
In conclusion, removing spaces is something you cannot ignore in programming. In this blog, I will share my thoughts about different kinds of ways to remove spacing from words, but I will mainly focus on how I think you should name your files.
What are my options?
Camel Case (camelCase)
To use camelCase, you strip the spaces from your words and you capitalize every word except for the first.
visible item count => visibleItemCount
This way of capitalizing is commonly used for variable declaration.
Pascal Case (PascalCase)
To write something in Pascal Case you start every word with capital and you remove the spacing.
visible item count => VisibleItemCount
This is often used to declare classes.
Kebab Case (kebab-case)
You can write something as kebab case by turning everything lowercase and replacing spaces with dashes (-).
visible item count => visible-item-count
This is commonly used to write readable URLs (example.com/blog/title-of-the-blog-post).
What about filenames?
Currently, Camel Case seems to have become the standard for naming files in front-end development. Why is that?
Over the past years, I had a few naming conventions. For instance, I was using Pascal Case for components, kebab-case for utilities, and camelCase for everything else. This way, I could expect what was inside the file without opening it. I like the idea of it, but things get tricky when stuff changes. FYI, file systems that are by default case insensitive, like MacOS, have issues when changing caps and submitting them to your repo. It’s a recipe for failure at one point or another. There is always a way to fix it, but in my opinion, it’s not worth the hassle. If I have to rely on the file name casing to know what I would expect inside the file, it would probably mean there are issues in my project structure in the first place.
Over time, I switched to all lower cases (kebab) and I love it. In essence, these are the key benefits of kebab as opposed to camelCase:
- filenames are consistent and less cluttered
- you don’t need to think about casing. All files are considered equal (but some files are more equal than others)
- refactoring is easier
- it avoids issues with filesystems that are case insensitive by default
To me, it seems like a small tradeoff for a lot of benefits.
In addition, I’m definitely not the only developer thinking this way. For example, Kent C. Dodds replied to a tweet about someone that had an issue with capitalization when his application got deployed to a (most likely) Linux server.
Conclusion: my preferred naming conventions
Long story short, this is how I like to name stuff in my codespaces nowadays:
- variables and utility functions => camelCase
- classes => PascalCase
- filenames => kebab-case (why?)
What’s your preferred naming convention? Let me know! 😁