camelCase vs snake_case: Which Is Faster to Type? We Counted the Keystrokes

1. Which Is Faster to Type: camelCase or snake_case?

Arguments about naming style usually stay in the abstract. We wanted a number. We pulled every multi-word identifier out of 1,350 snippets in our practice library, 3,026 names averaging 2.14 words each, and counted what it takes to type each one in four styles. A key press is one key going down, so Shift counts as a press.

camelCase wins on both measures. The difference in total presses looks modest because the letters are identical in every style; only the separators change. Look at the separators alone and snake_case costs exactly twice as much.

2. Why the Underscore Costs So Much

A camelCase hump is one extra press: hold Shift and type the next letter, which you were going to type anyway. An underscore is two presses, Shift and the minus key, and both are pinky jobs. If you shift with the left hand, which is the right technique for a right-hand key, you use both pinkies for one character.

The minus key also sits at the far right of the number row, the longest reach a right pinky makes on a standard keyboard. Python and Rust programmers make that reach every time they type a name like max_retry_count.

Here is that one name in each style. The 13 letters are the same every time; only the two word breaks differ.

This is part of a wider pattern: the pinkies already do more than a third of all key presses in code, as our keystroke analysis shows, and snake_case adds to that load.

3. Does 10% Matter?

Less than the headline suggests. Multi-word names are 15.6% of the non-space characters in our sample. Writing all of them in snake_case instead of camelCase adds about 1.4% to the total number of key presses in a codebase.

It is not spread evenly. The underscore appears 15.7 times per 1,000 characters in our Python snippets, 14.0 in C and 9.9 in Rust, against 0.7 in JavaScript and 0.2 in Java. If you write Python, C or Rust, it is one of your most-typed symbols; in JavaScript you rarely touch it.

Autocomplete shrinks it further. You type a name in full once, when you declare it; after that your editor usually finishes it for you. Where the cost shows up is in new code, quick scripts and REPL sessions, where you type names out by hand, and in the pinky, which takes the extra work whether or not your speed changes.

4. Which Is Easier to Read?

Typing is only half the question. Code is read far more often than it is written, and here the research is genuinely mixed.

• •

  A 2009 study by Binkley and colleagues at the International Conference on Program Comprehension reported an accuracy advantage for camelCase.

• •

  A 2010 eye-tracking study by Sharif and Maletic found no difference in accuracy, but programmers recognised underscore-style names more quickly. Most of its participants had been trained in the underscore style.

• •

  A later journal paper by the same group, pooling five studies and 150 participants, concluded that experienced developers are barely affected by identifier style, while beginners did better with camelCase on accuracy and effort.

The fair reading: style matters most for beginners, and familiarity matters more than either style. A Python developer reads snake_case fastest because that is what they read all day.

5. What Each Language Expects

Most languages settled this long ago. Here is what each one's official or dominant style guide says:

And here is what the names in our snippets actually use:

The conventions hold up. JavaScript is 84% camelCase, Python 70% snake_case, Rust 75% snake_case. PascalCase is large in Java, TypeScript and Python because class and type names use it. PHP is the one genuine mix: 39% camelCase, 32% snake_case.

6. What About kebab-case, PascalCase and Constants?

kebab-case (user-name) ties camelCase at 11.39 presses per name: one hyphen per break and no Shift. It would be the cheapest style of all, but most languages read a hyphen as minus, so it is limited to CSS, HTML attributes, URLs and Lisp-family languages.

PascalCase (UserName) costs one Shift more than camelCase per name, 12.39 presses. You will mostly type it for class and type names, where every mainstream convention asks for it anyway.

SCREAMING_SNAKE_CASE (MAX_RETRY_COUNT) is the convention for constants in most languages. It made up 122 of our names, mostly in C, where macros put it at 21% of all multi-word names. It is the most expensive style to type: every letter needs Shift, or you toggle Caps Lock on and off. And Caps Lock does not help with the separators, because it only affects letters. Every underscore still needs Shift and the minus key.

7. What to Do

• •

  Follow your language. A codebase that mixes styles costs more in reading time than any style costs in typing.

• •

  Shift with the opposite hand. For an underscore, hold left Shift and press minus with the right pinky. It splits the work between both hands instead of contorting one.

• •

  Let autocomplete type long names. Declare once, then tab-complete.

• •

  Practise the reach. If you write Python or Rust, the underscore is one of your most-typed symbols. Our Python and Rust tracks drill it on real code.

8. Method

We extracted every identifier from 1,350 snippets across nine language tracks and kept the 3,026 with more than one word: camelCase, PascalCase, snake_case and SCREAMING_SNAKE_CASE names, plus kebab-case names from HTML and CSS. Each name was split into words and rewritten in every style. Presses count every key: letters, separators and Shift. An underscore is Shift plus minus, a camelCase hump is Shift, a hyphen is one press. Pinky presses assume touch typing on a US keyboard, with Shift on the opposite hand. Names with runs of capitals, such as parseHTTPResponse, were left out because there is no single correct way to split them. Readability findings come from the published studies linked above; we did not measure reading.

9. Frequently Asked Questions