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 by 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 allows us to still read it.

For example, if you declare a variable to indicate the visible item count:

visible item count = 5;

Javascript would try to treat every word as a different concept. This means it treats visible, item, and count as individuals.

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?

Camelcase (camelCase)

To use camelCase, you strip the spaces from your words and capitalize every word except 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 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?

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 used 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, 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 consider 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 not the only developer thinking this way. For example, Kent C. Dodds replied to a tweet about someone who had an issue with capitalization when his application was deployed to a (most likely) Linux server.

KCD Twitter message

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

What’s your preferred naming convention? Let me know!