Why you should use snake_case instead of camelCase for variable names

Date: 2024-12-04 | create | tech | programming | snake-case | camel-case |

I stumbled upon a Twitter thread that made the best case for a variable name format I've yet seen.

The claim is that snake_case is better than camelCase and I kind of agree - here's why:

Variable name formats

Before we dive into snake_case vs camelCase I wanted to make sure we're on the same page wrt what these formats mean.

Basically there are many common ways to format variable names - each with their own pros and cons:

  • snake_case
  • SCREAMING_SNAKE_CASE
  • camelCase
  • PascalCase

Among others. Here we'll be comparing snake_case (common in langs like Python and Rust) against camelCase (common in langs like JavaScript and C#).

Why snake_case is better than camelCase

The thread author argues that snake_case is better than camelCase as it's easier to read:

  • snake_case has greater contrast in letter heights than camelCase
  • Higher contrast means easier to read
  • Easier to read means easier to understand
  • Understanding code is crucial to working with it well

Thus snake_case > camelCase.

snake_case vs camelCase

I created a p5js sketch to visualize this difference:

  • snake_case minimum contrast between words: (13 - 0) = 13
  • camelCase minimum contrast between words: (17 - 13) = 4

(These numbers are pulled from the 2d web context and I believe are pixel units. This means the absolute number will be different depending on display but the ratio should remain similar.)

This is a pretty big jump in contrast with snake_case having ~3x higher contrast in word breaks which may make it easier to read / scan.

Another big benefit is that it cuts out bikeshedding around edge cases like how to capitalize an acronym.

Some examples:

  • user_id - userId or userID?
  • find_css_string_in_js_file - findCssStringinJsFile or findCSSStringInJSFile?

In snake_case - every word is lowercase.

Why camelCase may still be better than snake_case

It should come as no surprise that there was some pushback to this argument.

The main counterarguments were:

  • camelCase is easier to type (shift + letter is easier than _)
  • camelCase variable names are shorter - thus easier to read and type
  • Many langs prefer camelCase in their style guides so it's better for consistency

These are all valid points and largely consistency in a codebase leads to better understandability long-term so shouldn't be discounted.

Should you switch from camelCase to snake_case?

As always it depends and you have to weigh the tradeoffs for your own situation.

The goal really is around readability of code in order to make understanding it that much easier. snake_case seems to have an edge here but if you're mixing snake_case with other casing formats it can lead to harder to read code overall.

As a general rule:

  • Pick a format style
  • Try to make it consistent in your codebase (better if it's consistent with the code / environments you use as well)

Personally I've been writing Python professionally for several years and we tend to prefer snake_case over there. It was a bit of a switch from the camelCase I was used to before that but largely I've enjoyed it.

Going forward I will probably prefer snake_case for variable names but stick with PascalCase for classes / modules / properties as that seems more consistent overall.

Next

If you want to play around with some variable name casing, check out my snake case vs camel case sketch on HAMY GAMES.

If you liked this post please leave a like, comment, and share w your network for the algorithm.

You might also like:

Want more like this?

The best / easiest way to support my work is by subscribing for future updates and sharing with your network.