Why the convention matters more than the letters
A naming convention is just an agreed way to write a name with no spaces in it. Almost no programming language allows a space inside a variable name. So user account id has to become something else, like userAccountId or user_account_id. Which exact style you pick matters less than picking one and sticking to it. Most of the value comes from being predictable.
Think about a codebase where every function uses camelCase and every constant uses SCREAMING_SNAKE_CASE. A reader can guess what kind of thing a name refers to before they even look it up. A codebase that mixes styles at random loses that signal. The reader has to check every single time instead of just knowing.
The conventions, and where each one lives
camelCase lowercases the first word. It capitalizes the first letter of every word after that: userAccountId. It’s the standard for variables and functions in JavaScript, TypeScript, Java, and C#. Most JSON APIs written by JavaScript-first teams use it for properties too.
PascalCase capitalizes every word, including the first one: UserAccountId. The same language communities that use camelCase for variables often switch to PascalCase for class and type names. UserAccountId might be a class, while userAccountId is one instance of it, sitting right there in the same file.
snake_case lowercases every word and joins them with underscores: user_account_id. It’s the standard style in Python for variables and functions. Ruby uses it too. So does most SQL, for table and column names. JSON APIs written by Python-first teams tend to use it as well.
SCREAMING_SNAKE_CASE is snake_case, but fully uppercased: USER_ACCOUNT_ID. Nearly every language reserves this one for constants and environment variables. That makes it more universal than the others on this list. A MAX_RETRY_COUNT constant looks the same whether the code around it is Python, Java, or C.
kebab-case lowercases every word and joins them with hyphens: user-account-id. Most languages won’t allow a hyphen inside a name, since the parser reads it as subtraction. So kebab-case shows up outside actual code: in URL slugs, in CSS class names, in HTML attributes, and in flags like --dry-run.
dot.case and path/case are narrower still. Dotted names show up in config keys and package scopes. Slash-separated names show up in file paths and API routes. Neither one is really a naming choice on its own. Each one just reflects syntax that already exists in that context.
Picking a convention usually isn’t a choice
For most of these, you don’t actually choose. The language and its tools choose for you. Fighting the local convention creates friction everywhere, since formatters, linters, and autocomplete all expect it. Writing user_account_id as a JavaScript variable will still run. It will look foreign to every other JavaScript developer who opens the file, and some linters will flag it outright. The one real judgment call most teams face is what to do with acronyms.
The acronym problem
Should an acronym inside a name keep its own capitalization? Or should it fold into the surrounding style like any other word? XMLHttpRequest treats “XML” and “HTTP” as their own units, always uppercase. XmlHttpRequest treats them as ordinary words, just capitalized once at the start. Both choices are reasonable. Style guides don’t all agree here either. Some guidelines prefer treating an acronym as one plain word in most contexts. A lot of hand-written code keeps acronyms fully capitalized, out of habit more than rule. Neither choice is wrong on its own. It becomes a real problem only when one codebase does both inconsistently. Readers start guessing whether Url and URL even mean the same thing.
Converting between conventions
Naming styles collide most often at a system boundary. A Python backend returns JSON with snake_case keys. A JavaScript frontend expects camelCase properties by convention. A database uses snake_case columns. An ORM maps them onto camelCase or PascalCase fields automatically. This kind of conversion is mechanical. That’s exactly why it’s worth automating instead of retyping by hand. A name typed twice is a name that will eventually get typed wrong once.
Converting correctly starts with splitting a name back into its separate words. That’s harder than it sounds once acronyms show up. XMLHttpRequest needs to split into three words: XML, Http, and Request. Not thirteen separate letters. Not one long unbroken word either. The rule that gets this right: split before a capital letter that’s followed by a lowercase letter. Also split after a run of capitals in a row. Skip that rule, and the result comes out shredded or wrong.
Check your own identifiers
The case converter on this site handles that splitting automatically. Paste one identifier, or a whole list of them, one per line. It converts every one into every common style at once. A toggle lets you choose whether acronyms stay uppercase or fold into the surrounding case. Getting that toggle wrong is a small mistake on a short example. It compounds fast across a real codebase. Word repetition and rhythm covers the same underlying pattern. Small, repeated choices add up to something a reader notices, even when no single instance looks wrong on its own.