TypeVelo.
← Drills Hub

camelCase & snake_case Drill

Shift _ camelCase snake_case

Every passage contains: _ · rowCount row_count

Net 0 wpmGross 0 wpmAcc 100%
start_time pageSize keyPress rowCount pageSize userName wordList userName filePath row_count total_value page_size startTime end_date errorRate key_press userName startTime page_size rowCount user_name totalValue total_value error_rate userName word_list user_name row_count startTime rowCount row_count end_date row_count row_count totalValue total_value filePath end_date keyPress key_press

QWERTY layout assumed. Backspace corrects; uncorrected errors count against net WPM.

In ordinary prose, a missed capital is a style problem — "mcdonald's" still reads correctly even without the capital M. In code, it's a different kind of mistake entirely: rowCount and rowcount are two different names as far as most programming languages are concerned, so a case slip doesn't just look wrong, it can point at something that doesn't exist or silently create a second, unintended variable. The Capitalization Timing Drill trains shift timing for natural-language capitals; this drill trains the same physical motion where getting it wrong has consequences a sentence never has.

camelCase and snake_case solve the same problem — a multi-word identifier with no spaces allowed — in two different ways, and each puts its interruption in a different place. camelCase drops a capital letter wherever a new word starts inside the identifier, so the interruption moves depending on which letters happen to be involved. snake_case uses an underscore in the same spot instead, and because the underscore always lives on the same key, that interruption never moves — it's the identical right-pinky reach every single time, regardless of which words it's separating.

Neither style gives the hand the pause a real space would. A space marks a clean boundary the hand can use to reset; a mid-word capital or underscore arrives while the hand is still mid-motion, with nothing to signal it's coming except the word itself.

Why This Drill

A capital in rowCount can land on any finger, depending on which letter happens to start the second word — pageSize's capital falls to the left ring finger, userName's to the right index, wordList's to the right ring finger. There's no single motion to rehearse, because the keyboard position of the interruption changes every time. That variability is what makes camelCase's mid-word capitals harder to automate than an equivalent number of sentence-start capitals, which always land in roughly the same rhythm relative to a pause.

snake_case removes that variability and replaces it with a different demand. The underscore is a shifted press of the same right-pinky key every time, so the motion itself never changes — what has to be judged correctly is exactly where in the identifier it belongs, since row_count with the underscore one character off no longer matches the name a program is expecting. Running both styles in the same drill makes the contrast direct: one interruption that moves and varies by letter, one that's fixed but has to land in precisely the right place.

Why a Case Mistake in Code Isn't Just Untidy

A misspelled word in a sentence is still usually readable; a mistyped identifier in code often isn't recognised at all. rowCount and rowcount refer to two separate things as far as most languages are concerned, so this drill's mid-word capitals and underscores carry a kind of stakes that an ordinary capitalisation slip in prose never does — one of the everyday realities the Typing for Programming Work guide covers in more general terms.

camelCase: An Interruption That Moves Around the Keyboard

Because the capitalised letter is whatever happens to start the second word, the finger responsible for it changes from one identifier to the next — errorRate's capital falls to a different finger than pageSize's does. There's no fixed motion to drill here beyond the general skill of hitting Shift precisely mid-word, since the specific letter and finger involved keep changing.

snake_case: The Same Reach, Every Single Time

The underscore lives on one key, reached by the right pinky with Shift held, and that never changes regardless of which words it separates. What varies instead is placement — row_count needs the underscore in exactly one position, and a single character's difference in either direction produces a name that no longer matches what the rest of the code expects.

Neither Style Gives the Hand a Real Pause

A space marks a clean, predictable boundary a typist's hand can use to reset before the next word. Both of these conventions exist specifically because a literal space isn't allowed inside an identifier, so whatever interruption stands in for one — a capital or an underscore — arrives mid-motion instead, with none of the natural break a real word boundary provides.

Frequently Asked Questions

Why does a capitalisation mistake matter more in code than in an ordinary sentence?

Because most programming languages treat rowCount and rowcount as two completely different names rather than two spellings of the same word, so a case slip in code can point at something that doesn't exist rather than simply looking untidy the way a missed capital in prose does.

Is camelCase's mid-word capital the same skill as the Capitalization Timing Drill trains?

It's the same underlying shift-timing motion applied somewhere the stakes are higher — that drill covers natural-language capitals like sentence starts and proper nouns, where a slip is cosmetic, while this drill applies the identical motion to identifiers, where a slip can break code.

Why is snake_case's underscore always the same reach, but camelCase's capital isn't?

The underscore lives on one fixed key regardless of the words around it, while a capital letter's position depends entirely on which letter happens to start the second word — different identifiers put that capital on entirely different fingers.

Does the underscore in snake_case work the same way as a hyphen joining two words?

No — the Hyphen & Dash Drill covers a hyphen that joins two already-complete words without needing Shift at all, while snake_case's underscore is a shifted reach standing in for a space that isn't allowed to exist in the identifier at all.

Which style is actually harder to type accurately, camelCase or snake_case?

They're hard in different ways rather than one being harder outright — camelCase asks for a shift-timing decision that changes with every identifier, while snake_case asks for the same motion every time but demands exact placement, so which one trips up a given typist tends to be personal rather than universal.